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ABSTRACT 


ON  DEADLOCK  IN  COMPUTER  SYSTEMS 

Richard  Craiy  Holt,  Ph.D. 

Cornell  University,  1971 

An  extensive,  unified  investigation  of  the  deadlock 
problem  in  computer  systems  is  presented.  The  investigation 
is  extensive  in  that  it  covers  a  wide  range  of  topics  within 
the  deadlock  problem,  including  deadlock  prevention, 
detection,  and  recovery,  and  it  develops  several  models  of 
interacting  processes  in  a  computer  system.  The  investigation 
is  unified  in  that  a  common  set  of  basic  definitions  is  used 
in  ail  the  models;  these  basic  definitions  specify  what  it 
means  for  a  process  to  be  "blocked"  or  "deadlocked"  and  for  a 
system  state  to  be  "sate"  from  deadlock. 

In  the  first  model  investigated,  the  processes  interact 
as  a  result  of  sharing  physical  devices  (or  objects  which 
behave  like  physical  devices)  .  This  model,  provides  a  simple 
intuitive  interpretation  of  most  of  the  previous  work  done  on 
the  deadlock  problem.  In  the  second  model  investigated,  the 
processes  interact  as  a  result  of  passing  messages.  The  third 
model  is  a  simple  combination  of  the  first  two  models  and  it 
allows  the  processes  both  to  share  physical  devices  and  to 
pass  messages. 

In  the  fourth  model,  called  a  "semaphore  system",  the 
processes  are  specified  in  considerably  more  detail  than  in 
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the  first  three  models.  In  a  semaphore  system,  each  process 
is  specified  by  a  flow  chart  in  which  the  flow  chart  boxes 
describe  the  process’s  resource  requests  and  releases.  By 
contrast,  in  the  first  three  models,  a  process  is  specified 
simply  by  which  resources  it  requests  and  releases. 

Intuitive  graphical  interpretations  are  given  for  each  of 
these  models;  these  models  (especially  the  first  three)  are 
easily  understood  and  are  suitable  for  presentation  in  a 
course  on  operating  systems. 

The  major  new  results  given  are  necessary  and  sufficient 
conditions  for  a  process  to  be  deadlocked  and  for  a  system 
state  to  be  safe  from  deadlock.  For  the  first  three  models, 
these  conditions  lead  to  a  number  of  fast  deadlock  detection 
and  prevention  algorithms.  These  algorithms  should  be  useful 
in  practical  systems,  and  suggestions  for  their  use  are  given 

i 

in  the  form  of  implementations  of  operations  which  allow 
processes  to  request  and  release  resources.  For  semaphore 
systems,  it  is  shown  that  it  is  decidable  if  a  process  is 
deadlocked,  but  the  question  of  whether  a  state  in  a  semaphore 
system  is  safe  from  deadlock  is  left  open. 
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CHAPTER  1.  INTRODUCTION 


1.1  The 

Deadlock 

Problem 

It 

is 

the 

purpose 

of  this 

thesis  to 

investigate 

the 

pr  oble  m 

of 

deadlock  in 

computer 

systems. 

Deadlock  is 

the 

situation  in  which  one  or  more  processes  within  a  system  are 
blocked  forever  due  to  requirements  which  can  never  be 
satisfied.  Deadlock  has  sometimes  been  called  deadly  embrace, 
knotting,  hangup,  circular  wait,  lockout,  and  interlock. 
There  has  been  some  inconsistenc y  in  computer  literature,  as 
’•lockout”  and  ’’interlock”  are  sometimes  used  to  refer  to  the 
temporary  blocking  of  processes  until  their  requirements  are 
satisfied.  In  this  thesis  ’’deadlock"  will  mean  that  the 
blocking  continues  forever.  (That  is,  deadlocked  processes 
will  remain  blocked  until  special  action  is  taken  by  an 
"external  force"  such  as  the  operator  or  the  operating 
system. ) 

Let  us  consider  a  simple  example  of  deadlock  which  can 
occur  when  there  are  two  processes.  Pi  and  P2,  and  two 
resources,  R1  and  R2.  Assume  that  a  process  can  not  release  a 
resource  (and  a  resource  can  not  be  preempted  from  a  process) 
while  the  process  is  waiting  for  a  request.  Suppose  resource 
H 1  has  been  allocated  to  process  PI  and  resource  R2  has  been 
allocated  to  process  P2.  Now  suppose  that  process  PI  requests 
resource  R2  and  process  P2  reguests  resource  Rl.  We  can 
represent  this  situation  as  a  directed  graph.  (See  Figure 
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1.1.) 

In  Figure  1. 1  the  directed  edges  have  the  following 
meanings: 

Edge  (HI,  PI)  means  Hi  has  been  allocated  to  PI  and  can  not 
be  allocated  to  another  process  until  released  by  Pi- 
Edge  (PI ,  H2)  means  PI  has  requested  B2  and  PI  can  not 

continue  until  PI  receives  R2. 

Edge  (R2,P2)  means  H2  has  been  allocated  to  P2  and  can  not 
be  allocated  to  another  process  until  released  by  P2. 

Edge  (P2,B1)  means  P2  has  requested  R1  and  P2  can  not 


continue 

until 

P2  receives  Hi. 

The  pro 

cesses 

shown  in  Figure 

1.1  are  deadlocked 

because 

the 

re  is  no 

way 

to  satisfy  the 

resource  requests 

so 

that 

pro 

cesses  PI 

and  P2 

can  continue. 

Unf ortun 

a tel y. 

all  deadlocks 

are  not  as  simple 

as 

this 

example.  Before  exploring  more  complicated  examples,  we  will 
discuss  how  the  study  of  the  deadlock  problem  is  a  part  of  a 
larger  field  of  knowledge  which  might  be  called  the  "Theory  of 
Operating  Systems”. 
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Figure  Jkl.  An  example  of  a  deadlock  involving  processes  ?1  and 
P2  and  resources  HI  and  R2. 
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1.2  Deadlock  and  the  Theory  of  Operating  Systems 

Although  a  considerable  amount  of  literature  has  been 
produced  about  operating  systems,  there  has  not  yet  emerged  a 
commonly  accepted  outline  of  the  ’’theory  of  operating 
systems”.  This  theory  would  form  the  core  of  a  graduate  major 
in  operating  systems,  and  would  consist  of  those  subject  areas 
which  are  of  vital  interest  to  designers  and  implementers  of 
operating  systems. 

Let  us  make  a  brief  conjecture  about  the  main  topics  in 
the  theory  of  operating  systems,  i.e. ,  about  the  theory  and 
models  used  by  an  operating  system  engineer.  Our  heritage 
from  programming  systems  (see  Rosen  [1966],  for  example), 
would  seem  to  indicate  that  these  topics  should  include  the 
study  cf  programs  such  as  loaders,  assemblers,  sorters,  and 
utilities.  Although  these  programs  are  important  and  should 
be  considered  as  part  of  an  operating  system,  it  seems  more 
convenient  to  regard  an  operating  system  as  a  virtual  machine 
upon  which  programs  execute.  That  is,  rather  than  regarding 
an  operating  system  as  a  collection  of  programs,  it  now  seems 
more  convenient  and  comprehensible  to  regard  an  operating 
system  as  a  virtual  machine,  on  which  other  programs  execute. 
(This  point  is  discussed  by  Saltzer  in  [1966].)  Under  this 
interpretation,  a  program  such  as  a  loader  is  written  to  run 
on  a  certain  virtual  machine.  Once  the  loader  has  been 
written,  it  can  be  ’’added”  to  the  virtual  machine  with  the 
result  that  the  virtual  machine  acquires  new  facilities 
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available  to  successive  programmers. 

An  Operating  System  as  a  Seguence  of  Virtual  Machines 

It  is  the  job  of  the  operating  systems  engineer  to 

provide  a  user  with  a  virtual  machine  which  is  convenient  for 
solving  the  user's  problem.  The  user  can  be  anyone  from  a 
learner  at  a  conversational  terminal  to  a  systems  programmer, 
and  different  users  should  be  provided  with  different  virtual 
machines.  Not  only  should  different  users  of  a  particular 
system  see  different  virtual  machines,  but  the  operating 
system  itself  should  be  constructed  as  a  seguence  of 

successively  more  sophisticated  virtual  machines.  This 
seguence  of  virtual  machines  has  been  called  "onion  layers”  by 
Mealy  [1966]  and  "hierarchial  levels"  by  Dijkstra  [1968].  We 
may  consider  the  first  virtual  machine  MO  in  the  seguence  to 
be  the  hardware.  To  this  basic  machine  MO  is  added  a  layer  of 

software  SO  to  implement  a  new  machine  Ml.  Then  to  Ml  is 

t 

added  another  layer  of  software  Si  to  implement  machine  M2, 
and  so  on.  (For  example,  see  Figure  1.2.) 

Dijkstra's  THE  multiprogramming  system  [1968]  is  an 
example  of  an  operating  system  implemented  in  this  fashion. 
In  the  THE  system,  layer  SO  is  the  CPU  manager  and  implements 
a  virtual  machine  Ml  in  which  each  process  has  its  own  virtual 
CPU;  layer  SI  implements  paging  so  that  a  program  executing  on 
M2  may  assume  that  it  has  an  entire  core  storage  to  itself, 
and  so  on.  In  practice  it  may  well  be  that  the  sequence  of 
machines  is  a  tree  structure  with  various  machines  available 
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at  the  higher  levels. 

Structure,  Correctness,  and  Efficiency  of  Operating  Systems 

It  is  the  job  of  the  operating  system  engineer  to  design 
the  seguence  of  virtual  machines  and  to  implement  them  by 
appropriate  software.  During  design  and  implementation  the 
operating  system  engineer  must  be  concerned  with  the  following 
areas: 

Structure.  What  is  the  structure  of  a  particular  virtual 
machine?  What  facilities  or  primitive  operations  does  it 
provide  for  the  user?  What  resources  must  be  reguested  by 
a  process  and  what  resources  can  be  assumed  to  be 
available  without  explicit  requests? 

Cor rect ness.  Do  the  structures  of  the  virtual  machines 
actually  provide  the  intended  facilities?  If  a  virtual 
machine  is  to  provide  all  processes  with  a  virtual  CPU,  do 
the  processes  actually  receive,  at  least  occasionally,  the 
use  of  a  CPU?  Is  a  virtual  machine  safe  from  destruction, 
so  that  it  is  guaranteed  to  continue  to  function 
correctly? 

Efficiency.  Will  the  virtual  machines  perform  their 
functions  using  a  reasonable  expenditure  of  system 
resources?  Are  users  provided  with  facilities  which  are 
convenient  to  use  and  not  too  costly?  Do  processes 
execute  at  a  sufficiently  fast  rate? 

In  short,  the  theory  of  operating  systems  should  provide 
examples  of  convenient  virtual  machines 


together  with 
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techniques  for  implementing  these  machines;  the  theory  should 
also  provide  methods  of  showing  the  correctness  and  efficiency 
of  these  virtual  machines. 

The  main  purpose  in  giving  this  brief  discussion  of  the 
theory  of  operating  systems  has  been  to  show  how  the  study  of 
deadlock  fits  into  a  larger  field  of  knowledge.  We  study 
deadlock  so  we  will  be  able  to  prove  that  the  virtual  machines 
in  an  operating  system  are  correct.  In  particular,  we  want  to 
be  able  to  show  that  processes  in  an  operating  system  will  be 
able  to  complete  their  work. 

Examples  of  Deadlock  in  Current  Systems 

One  of  the  major  advantages  provided  by  operating  systems 
is  the  ability  to  share  resources  among  processes.  Whenever 
resources  can  be  requested  and  held  by  processes,  deadlock  is 
a  potential  problem,  and  thus  the  operating  system  designer 
should  be  well  acquainted  with  solutions  to  this  problem. 

t 

One  might  argue  that  deadlock  is  of  little  interest  in 
current  operating  systems,  and  that  the  problem  is  apparently 
solved  because  it  is  seldom  observed.  It  is  true  that 
deadlock  caused  by  competition  for  devices,  such  as  tape  and 
disk  drives,  has  been  prevented  by  effective  ad  hoc 
procedures.  (See  Havender*s  article  [1968]  for  discussion  of 
such  procedures  used  in  OS/360.)  However,  it  is  not  at  all 
obvious  that  these  ad  hoc  methods  are  optimal,  and  further 
work  is  required  to  clarify  exactly  what  methods  are  possible 
and  are  least  costly. 
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la  spooling  systems,  such  as  ASP/OS/360  [IBM  1968d], 
deadlock  sometimes  occurs  due  to  competition  for  spooling 
space  on  the  disk.  The  problem  occurs  when  the  spooling  space 
becomes  completely  filled  with  input  records  for  jobs  waiting 
to  execute  and  output  records  for  jobs  not  finished  executing. 
There  is  no  way  to  recover  the  spooling  space  occupied  by  a 
partially  executed  job  (at  least  not  in  ASP/0S/36Q)  and  the 
only  way  to  recover  from  such  a  deadlock  is  to  restart  the 
system.  The  somewhat  crude  ad  hoc  solution  to  this  problem  is 
to  prohibit  (manually)  the  spooling  of  new  jobs  once  the 
utilization  of  spooling  space  becomes  too  high,  say,  above  80% 
utilization.  It  is  obvious  that  this  solution  is  costly  in 
terms  of  idle  spooling  space  and  it  is  not  obvious  that  this 
solution  is  anywhere  close  to  being  optimal. 

Deadlock  caused  by  faulty  synchronization  of  processes  is 
still  not  well  understood.  (See  Saltzer's  discussion  of  the 
lost  wakeup  problem  [1966]  and  Happaport’s  discussion  of  why 
the  original  design  of  Block-Wakeup  in  MULTICS  caused  deadlock 
[  1968].) 

Deadlocks  caused  by  faulty  synchronization  of  processes 
can  and  do  occur  in  systems  like  OS/360.  The  current 
solutions  to  these  problems  are  typified  by  the  following  two 
examples: 

(1)  If  a  job  in  OS/360  begins  waiting  (via  a  Wait  macro 
[IBM  1968a])  for  an  event,  the  system  has  no  way  of 
knowing  if  the  event  will  ever  occur.  While  the  job  is 
waiting  for  the  event  to  occur,  any  resources  allocated  to 
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the  job. 

including  core 

occupied. 

will  remain  idle.  To 

prevent 

waiting 

forever. 

OS/360 

allows 

an  arbitrary 

absolute 

li  mit 

of  30 

minutes 

waiting 

time  before 

cancelling  the  job  [IBM  1968c].  Why  30  minutes  and  not  5 
minutes  or  50  minutes? 

[2)  The  Enq-Deg  facility  in  OS/360  allows  processes  to 
gain  (by  Eng)  exclusive  control  of  a  resource,  and  then  to 
release  it  {by  leg)  [IBM  1968a].  The  simple  type  of 
deadlock  illustrated  in  Figure  1.1  can  occur  using 
Eng-Deq,  and  goes  undetected  by  the  system,  thereby 
allowing  deadlocked  processes  together  with  the  resources 
they  hold  to  remain  idle  for  an  indefinite  period  of  time. 
These  two  examples  illustrate  the  fact  that  in  OS/360,  methods 
of  deadlock  detection  are,  at  best,  rudimentary.  (In  Chapters 
3,  4,  and  5  we  develop  simple,  but  rigorous  methods  of 

detecting  deadlock.) 

With  the  introduction  of  parallel  processes  and 

i 

operations  to  synchronize  these  processes  in  high  level 
languages  such  as  PL/I  [IBM  1968b],  a  large  community  of  users 
has  at  its  disposal  the  means  to  deadlock  processes.  A 
hostile  user  of  an  OS/360  system  has  only  to  submit  the 
following  three  line  PI/I  program  to  cause  a  deadlock: 

REVENGE:  PROCEDURE  OPTIONS  (MAIN, TASK )  ; 

WAIT  (EVENT)  ; 

END  REVENGE; 

The  only  executable  statement  in  this  program  is 
•*  WAIT  (EVENT)  ;  ” ,  which  causes  the  program  to  begin  waiting  for 
an  event  which  will  never  occur.  The  user  will  not  be  charged 
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for  CPU  or  Input/Output  use  because  the  program  uses  neither. 
However,  any  resources  allocated  to  this  program,  such  as  the 
core  it  occupies,  will  remain  idle  until  the  deadlock  is 
removed  by  the  operating  system  or  by  a  keen  witted  operator. 

It  is  the  purpose  of  this  thesis  to  help  clarify  the 
nature  of  deadlock  problems  so  that  in  future  operating 
systems  the  handling  of  these  problems  will  be  more  elegant 
and  less  costly. 


SECTION  1.2 


11 


r- 


Each  process  has  a  virtual 
CPU  and  virtual  storage 


Each  process  has 
a  virtual  CPU 


Hardware 


Figure  1.2  An  operating  system  implemented  by  a  sequence  of 
virtual  machines.  (The  author  is  indebted  to  Weiderman  [1970] 
for  this  illustration.) 
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1.3  Related  J or k 

In  an  early  article  Leiner  et  al  [1959]  showed  that 
binary  precedence  matrices  can  be  used  to  determine  if  a  set 
of  conditions  in  a  computer  system  contains  a  con t radic t ion. 
Leiner  et  al  made  the  conjecture  that  "this  field  of 
’concurrent  logic1  is  a  new  and  important  aspect  of  logical 
design  that  may  eventually  become  as  vital  to  future  computer 
development  as  'switching  logic'  has  been  in  the  past."  The 
considerable  study  and  interest  during  the- past  ten  years  in 
the  synchronization  of  parallel  processes  seems  to  bear  out 
their  conjecture. 

Three  researchers  in  the  IBM  corporation,  Braude  [1961], 
Collier  [1968],  and  Murphy  [1968],  have  given  analyses  of  the 
problem  of  deadlock  when  the  only  interaction  among  processes 
is  through  the  sharing  of  resources,  each  of  which  consists  of 
a  single  unit.  This  situation  is  typified  by  the  sharing  of 
records  of  a  file,  or  by  sharing  a  set  of  files.  All  three 
authors  give  methods  of  deadlock  detection. 

Dijkstra  and  Habermann  have  given  a  method  for  preventing 
deadlock  when  the  maximum  resource  requirements  for  each 
process  are  known  in  advance.  Dijkstra 's  original  method 
[1965a]  applies  when  there  is  only  one  type  of  resource,  which 
contains  a  number  of  identical  units.  This  situation  is 
typified  by  a  system  of  processes  sharing  pages  of  core,  or 
sharing  tracks  on  a  disk. 

Habermann  [1967,1969]  extended  Dijkstra' s  method  to 
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handle  the  case  in  which  there  are  several  types  of  resources 
each  containing  a  number  of  units.  Doth  of  their  methods 
suffer  from  the  fact  that  their  algorithms  can  require 
execution  time  proportional  to  the  square  of  the  number  of 
processes.  (In  Chapter  3  we  give  an  equivalent  algorithm 
which  does  not  require  this  much  time.) 

Shoshani  [19693,19690]  has  given  a  definition  of  deadlock 
in  the  general  case  of  several  resources  each  with  a  number  of 
units.  Shoshani  gives  an  algorithm  for  detecting  deadlock 
which  is  similar  to  Habermann's  algorithm  for  preventing 
deadlock.  Shoshani  also  gives  an  optimal  method  tor  breaking 
a  deadlock  where  it  is  assumed  that  the  only  cost  involved  in 
breaking  the  deadlock  is  a  charge  for  each  resource  unit  which 
is  preempted.  Shoshani  also  develops  algorithms  for  detecting 
or  preventing  deadlock  when  the  entire  sequence  of  requests 
and  releases  for  each  process  is  known  in  advance. 

He talker  [1970]  has  done  further  work  on  this  last 

i 

algorithm  of  Shoshani's.  Hebalkar  was  able  (1)  to  give  a 
considerably  faster  algorithm  than  Shoshani's  algorithm  for 
the  case  of  a  single  type  of  resource  and  ( 2 )  to  show  that  for 
several  types  of  resources  the  problem  is  inherently 
difficult,  and  that  a  fast  algorithm  is  " unlikely". 

The  models  of  Dijkstra,  Habermann,  and  Shoshani  are  all 
subcases  of  the  graph  model  given  in  Chapter  3;  and  this  graph 
model  with  Its  method  of  deadlock  detection  by  graph 
reductions  provides  a  unified  and  intuitive  interpretation  of 


their  worx. 
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Hassell  [1970]  is  presently  investigating  a  model  which 
is  similar  to  the  models  of  Hafcermann  and  Shoshani  and  the 
model  given  in  Chapter  3  of  this  thesis.  He  has  independently 
developed  an  algorithm  similar  to  Algorithm  3.2  (given  below) 
which  provides  fast  deadlock  detection  and  prevention. 

A  number  of  articles  have  been  written  about  "parallel 
program  schemata".  (See  [Adams  1968]  for  a  summary  of  this 
work.)  The  main  motivation  for  this  work  has  been  to  discover 
criteria  which  guarantee  that  a  program,  run  as  a  set  of 
parallel  processes,  will  always  yield  the  same  result 
regardless  of  processor  speeds.  If  it  is  guaranteed  that  the 
program  always  yields  the  same  result,  then  the  program  is 
called  ^terminate.  In  order  to  show  that  a  program  is 
determinate  we  must  knew  that  the  program  always  completes  its 
computation  (or  never  completes  its  computation!).  The 
studies  of  deadlock  and  parallel  program  schemata  overlap  in 
that  in  both  we  wish  to  know  criteria  guaranteeing  completion 
of  processes.  One  of  the  most  recent  works  on  parallel 
program  schemata  is  Slutz’s  thesis  [1968].  In  Slutz*s  model, 
data  transformations  ("machine  operations")  are  initiated  and 
are  terminated  according  to  the  values  of  certain  global 
counters.  These  counters  are  very  similar  in  function  to 
Dijk.stra*s  semaphores,  which  provide  process  synchronization 
in  the  TEE  system  [ Di jkstra  1968],  Slutz  was  able  to  show  (a) 
that  under  fairly  general  conditions  [pg.  113,  Slutz  1968],  it 
is  decidable  if  a  parallel  program  schemata  is  determinate  and 
(b)  that  certain  questions  about  equivalence  among  parallel 
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program  schemata  are  decidable.  While  Slutz's  work  has  a 
considerably  different  outlook  from  the  present  work,  his 
results  are  closely  related  to  the  results  given  below  in 
Chapter  6. 

The  evolution  of  the  OS/360  system  provides  an 
interesting  example  o±  a  change  of  resource  allocation  policy 
required  when  the  deadlock  problem  is  originally  ignored.  In 
1966  Witt  [  1966  ]  wrote  in  the  IBM  Systems  Journal,  ”Tn  a 
multitask  operation,  competing  requests  for  service  or 
resources  must  be  resolved...  In  most  cases  ...  the  system 
relies  upon  a  priority  number  provided  by  the  user.  The 
reason  for  this  is  that  the  user  can  best  select  priority 
criteria.*1  Unfortunately,  it  soon  became  obvious  that  if 
priority  was  the  only  criterion  for  resource  allocation, 
deadlock  could  be  a  serious  problem,  and  two  short  years 
later,  [lavender  [  1  968  ]  wrote  in  the  IBM  Systems  Journal  that, 
11  The  original  multitasking  concept  of  the  operating  system 

t 

envisioned  relatively  unrestrained  competition  for  resources 
to  perform  a  number  of  tasks  concurrently.  The  system  acted 
mainly  as  a  dispenser  and  collector  of  these  resources.  But, 
as  the  system  evolved,  many  instances  of  task  deadlock  were 
uncovered...**  Havender  goes  on  to  give  the  method  used  in 
OS/ 3  60  to  prevent  deadlock  due  to  resource  allocation. 
Havender’s  method  is  discussed  further  in  Section  3.9  where  it 
is  called  the  ordered  resources  policy. 
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1  -  **  and  Contributions 

In  this  thesis  we  present  several  models  of  processes 
interacting  in  a  computer  systems-  These  models,  especially 
the  models  of  Chapters  3,  4,  and  5,  are  easily  understood  and 
should  be  suitable  for  presentation  in  a  course  on  operating 
systems-  Necessary  and  sufficient  conditions  for  detection 
and  prevention  of  deadlock  are  given  for  most  of  these  models. 
A  number  of  fast  detection  and  prevention  algorithms,  which 
should  be  useful  in  practical  systems,  are  developed  for  the 
models. 

The  main  contributions  of  this  thesis,  as  they  appear  in 
the  chapters,  are  as  follows: 

Ck-lH^er  2_.  Formal  definitions  are  given  of  the  terms 
’’deadlock",  "process",  "operation",  and  "system".  The 
definition  of  deadlock  is  simpler,  and  of  more  general 
applicability,  than  the  only  previous  formal  definition  of 
deadlock,  which  was  given  by  Shoshani  [1969a]. 

Chapter  J-.  A  formal  model  of  systems  in  which  processes 
compete  for  reusable  resources  is  presented.  This  model 
provides  a  simple  intuitive  interpretation  of  most  of  the 
work  done  up  to  this  time  on  the  deadlock  problem.  A 
number  of  new  and  fast  algorithms  for  detecting  and 
preventing  deadlock  are  given. 

Chapter  4_.  A  formal  graph  model  of  systems  in  which 
processes  interact  by  exchanging  messages  is  presented. 
This  model  is  analogous  to  the  model  of  Chapter  3,  and 
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provides  a  simple  intuitive  interpretation  of  this  type  of 
interaction  among  processes.  Necessary  and  sufficient 
conditions  are  given  (a)  for  a  process  to  be  deadlocked 
and  (b)  for  a  system  to  be  safe  from  deadlock.  A  fast 
deadlock  detection  algorithm  is  given  for  an  important 
subcase  of  this  model. 

Ch^£t^£  5.  The  models  of  Chapters  3  and  4  are  combined 
into  a  general  model  in  which  processes  may  interact  both 
(a)  by  competing  for  reusable  resources,  and  { b )  by 
exchanging  messages.  With  the  possible  exception  of 
Habermann*£  "system  of  abstract  machines"  [1967],  this  is 
the  first  model  incorporating  both  of  these  types  of 
in teractio ns.  Necessary  and  sufficient  conditions  for 
deadlock  are  given.  A  fast  deadlock  detection  algorithm 
is  given  fcr  an  important  subcase  of  the  model.  Practical 
methods  of  implementing  deadlock  detection  and  prevention 
are  given. 

t 

Chapter  6.  A  model  of  systems  which  includes  the  flow 
charts  of  the  interacting  processes  is  investigated.  This 
model  uses  more  detailed  information  about  the  processes 
tnan  do  the  models  of  Chapters  3,  4,  and  5;  those  models 
include  no  knowlege  of  the  "internal  structure"  of  the 
processes.  In  the  model  given  in  Chapter  6,  interactions 
are  caused  by  global  counters  which  behave  like  Dijkstra’s 
semaphores  [  1965a].  It  is  shown  that  it  is  decidable 
whether  the  processes  in  the  system  are  deadlocked.  It  is 
also  shown  that  it  is  decidable  whether  the  counters  are 
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bounded,  and  that  when  the  counters  are  bounded,  it  is 
decidable  whether  a  system  state  is  safe  from  deadlock. 

The  algorithms  given  in  this  thesis  are  given  in  a 
combination  of  ?L/I  [IBM  1968b]  and  English.  The  exact  data 
structures  used  by  the  algorithms  are  not  specified.  It  is 
hoped  that  the  algorithms  are  presented  at  a  "high"  enough 
level  to  be  easily  read  and  comprehended,  and  yet  at  a  ’‘low1’ 
enough  level  so  that  they  can  easily  be  translated  into  a 
procedural  language  such  as  PL/I.  (This  method  of  presenting 
algorithms  was  inspired  by  Dijkstra  [1969].)  Most  of  the 
algorithms  given  have  been  implemented  in  PL/I  and  a  number  of 
them  have  been  tested  using  the  multitasking  facility  of  PL/I 
[IBM  1  9  68b  J. 

The  algorithms  and  figures  given  in  this  thesis  will  be 
found  at  the  end  of  the  section  in  which  they  are  first 


discussed. 
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CHAPTER  2.  DEADLOCK  DEFINITIONS  AND  STRATEGIES 

In  this  chapter  we  give  a  formal  definition  of 
'’deadlock",  and  we  discuss  what  strategies  are  available  to 
leal  with  the  deadlock  problem-  Definitions  given  in  this 
chapter  are  abstract;  as  a  result,  the  definitions  can  be 
applied  to  a  wide  range  of  systems  where  the  process 
interactions  arise  from  various  sources. 

2. 1  Interaction  Among  Parallel  Processes 

One  of  the  basic  features  of  modern  operating  systems  is 
the  existence  of  several  processes  executing  in  parallel. 
Hardware  processes,  such  as  channels  and  CPUs,  physically 
execute  in  parallel.  Software  processes,  such  as  user  jobs 
and  spooling  routines,  logically  execute  in  parallel.  Even 
though  the  software  processes  may  all  execute  on  a  single  CPU, 
the  logic  of  process  interactions  is  identical  to  the 
situation  in  which  the  processes  simultaneously  execute 
operations.  (See  [  pg.  82,  Dijkstra  1965a].)  On  a  single  CPU 
system,  the  software  processes  have  their  intervals  of 
execution  spread  out  in  time;  however,  the  logic  of  process 
execution,  resource  sharing,  and  interprocess  communication 
are  the  same  for  single  and  multiple  CPU  systems. 

It  is  convenient  to  regard  certain  processes,  such  as 
user  jobs,  as  independent  parallel  processes.  They  are  called 
” independent”  because  these  processes  should  perform  the  same 
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logical  operations  regardless  of  what  other  processes  execute 
concurrently.  When  processes  compete  for  system  resources  we 
will  say  there  are  implicit  interactions  among  the  processes. 
In  Figure  1.  1  implicit  -interactions  of  the  two  processes  have 
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another  operation  until  another  process  performs  the  operation 
which  releases  the  required  resource  or  sends  the  required 
signal.  In  turn,  the  process  or  processes  which  are  capable 
of  unblocking  the  first  process  may  be  blocked  by  yet  other 
processes,  and  so  on.  The  result  is  that  at  any  particular 
point  in  time  there  may  exist  a  complicated  set  of  conditions 
or  precedences  which  dictate  the  order  of  execution  of  the 
processes.  If  there  is  no  way  to  satisfy  these  conditions 
then  we  say  the  system  is  deadlocked. 
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2.2  Def initio n  of  Deadlock 

In  this  section  we  give  a  number  of  formal  definitions 
about  deadlock.  We  will  not  be  concerned  with  the  source  of 
the  interactions  among  processes.  We  will  assume  only  that 
the  system  state  determines  which  processes  are  blocked  and 
that  processes  which  are  not  blocked  can  cause  changes  in  the 
state  of  the  system. 

We  define  a  system  as  a  pair  (SIGMA ,  PI)  where  SIGMA  is  a 
set  of  cistern  states,  {S,T,U,V, W,. ,  and  PI  is  a  set  of 
processes,  {P 1 , P2, P3,, . . } .  (We  do  not  insist  that  SIGMA  and 
PI  be  finite  sets.)  A  system  state  will  often  simply  be 
called  a  state. 

We  define  a  process  as  a  partial  function  from  the  system 

states  into  the  subsets  of  system  states;  if  Pi  maps  system 

state  5  into  a  subset  containing  system  state  T  then  we  write 

S  - i- >  T 

and  we  say  process  Pi  can  change  the  system  state  from  S  to  T. 
(For  short,  one  can  read  "S  -i->  T”  as  "Pi  takes  S  to  T".)  We 
call  the  change  of  state  from  S  to  T  an  operation  by  process 
Pi.  In  Figure  2.1  we  illustrate  a  system  whose  set  of  states 
is  SIGMA  =  {S,T,U,V}  and  whose  set  of  processes  is  PI  =  {PI, 
P2),  The  operations  in  this  system  are: 

S  -1->  T,  S  - 1 ->  U,  S  -2->  U, 

T  - 1->  S,  T  - 2 - >  S,  T  -2->  V, 

u  - 1->  V,  v  -i->  u. 

If  for  processes  Pi,  Pj,  Px,  the  following  changes 
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of  state  are  possible, 

S  -i->  T,  T  - j->  0,  .  „  .  ,  V  -x->  W, 

then  we  write 

5  -*->  W, 

and  we  say  the  system  can  change  from  state  S  to  state  W.  (If 

S  -  w  we  also  write  S  -*->  W.)  In  the  system  in  Figure  2.1 

S  -2->  0  and  U  -1->  V  and  therefore  S  -*->  V. 

The  notion  of  "processes”  in  a  computer  system  is  well 
known  and  has  been  described  by  various  authors  including 
Dijkstra  [1965a],  Saltzer  [1966],  and  Lampson  [1968].  Our 
definition  of  "process"  is  noteworthy  in  that  it  is  quite 
simple  and  at  the  same  time  formal.  (See  [Horning  1969]  for 
another  formal  definition  of  "process".)  Despite  its 
simplicity  (or  perhaps,  because  of  its  simplicity)  our 
definition  will  be  both  convenient  and  sufficient  for  our 
investigation  of  deadlock. 

If  the  system  is  in  state  S  and  there  exists  no  operation 

by  process  Pi  which  can  change  the  state  of  the  system  (i.e. 

if  partial  function  Pi  is  undefined  for  argument  S) ,  then  we 
say  process  Pi  is  blocked.  We  define: 

If  there  exists  no  T  such  that  S  -i->  T  then  process 
Pi  is  blocked  in  state  S. 

In  the  system  in  Figure  2.1,  process  P2  is  blocked  in  U  and  V. 

If  the  system  is  in  state  S  and  process  Pi  is  blocked  and 
will  remain  blocked  no  matter  how  the  system  changes  states 
then  we  say  process  Pi  is  deadlocked.  Wo  define: 

If  for  all  T  such  that  S  -*->  T, 


process  Pi  is  blocked 
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of  deadlock: 


If  process  Pi  is  deadlocked  in  state  5  and  S  -*->  T 
then  process  Pi  is  deadlocked  in  state  T. 

Thus  our  definition  implies  that  once  a  process  is  deadlocked, 
it  will  remain  deadlocked  forever. 
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deadlock  states,  but  there  are  no  total  deadlock  states. 

If  a  process  is  not  deadlocked,  we  know  is  that  it  is 
possible  that  the  process  may  execute  again.  The  situation 
where  a  process  never  executes  again  (whether  or  not  it  is 
deadlocked)  will  be  called  effective  deadlock.  Of  course,  any 
deadlock  is  an  effective  deadlock.  The  following  is  an 
example  of  an  effective  deadlock  which  is  not  a  deadlock:  a 
low  priority  job  with  a  large  core  request  waits  forever  while 
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a  sequence  of  high  priority  jobs  with  many  core  requests  keeps 
the  core  too  fragmented  to  grant  the  large  request.  This 
situation  is  not  a  true  deadlock  because  it  is  always  possible 
that  the  high  priority  jobs  will  release  a  sufficient  quantity 
of  core  to  enable  the  low  priority  job  to  continue.  In  Figure 
2.1,  process  P2  will  be  effectively  deadlocked,  but  not 
deadlocked  in  the  infinite  sequence  of  operations 
S  ~ 1->  T,  T  -1->  S,  S  - 1 - >  T,  T  - 1- >  S,  ... 

(In  [Holt  1971]  "effective  deadlock"  is  called  "permanent 
blocking". ) 

If  the  system  is  in  state  S  and  no  matter  how  the  system 
changes  states,  deadlock  will  not  occur,  we  say  S  is  a  safe 
state.  Wore  formally,  we  define: 

If  for  all  T  such  that  S  -*->  T,  T  is  not  a  deadlock 
state,  then  S  if  a  safe  state.  If  one  or  more  states 
in  a  system  are  safe  then  the  system  is  said  to  be 
safe, 

It  follows  immediately  from  this  definition  that  if  the  system 
begins  in  a  safe  state  then  it  will  always  remain  in  a  safe 
state.  There  are  no  safe  states  in  Figure  2.  1.  As  we  will 
see  later,  the  usual  method  of  preventing  deadlock  is  to 
prohibit  seme  of  the  possible  changes  of  state  of  the  system, 
thereby  creating  a  system  with  safe  states. 
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Figure  2.__1  Example  of  a  system  in  which  process  ?2  can' 


deadlock. 
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2.3  An  Example  in  Resource  Sharing 


We  will  now  motivate  these  definitions  by  applying  them 
to  a  system  consisting  of  two  processes  which  share  two 
identical  units  of  a  resource.  Assume  that  each  process  is 
able  to  request  only  one  unit  of  the  resource  at  a  time  and 
that  a  process  holding  units  can  release  only  one  unit  at  a 
time.  In  this  system,  each  process  is  in  one  of  the  following 
sta  tes : 
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A  process  may  change  states  from  2  to  0  or  from  4  to  2  by 
releasing  a  unit. 

We  wall  represent  each  state  of  the  system  as  Sjk  where  j 
is  the  state  of  process  PI  and  k  is  the  state  of  process  P2. 
For  example,  if  the  state  of  PI  is  1  (PI  holds  no  units  and 
has  requested  one  unit)  and  the  state  of  P2  is  4  (P2  holds 
both  units),  then  the  system  state  is  S14.  The  possible 
changes  of  state  in  this  system  are  illustrated  in  Figure  2.2. 
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In  Figure  2,2  the  vertical  edges  are  operations  by  Pi  and 
the  horizontal  edges  are  operations  by  p2.  Edges  directed  to 
the  right  and  edges  directed  down  represent  requests  and 
acquisitions  of  units;  edges  directed  to  the  left  and  edges 
directed  up  represent  releases  of  units. 

Process  PI  is  blocked  whenever  it  has  requested  a  unit, 
but  no  more  units  are  available-  For  example,  in  system  state 
S 1 4  process  PI  has  requested  a  unit,  but  both  units  have  been 
allocated  to  process  P2.  In  Figure  2,1  we  can  tell  that  PI  is 
blocked  in  Si  4  because  the  node  S14  has  no  edges  labelled  ’’I” 


directed  away 

from  it. 

Deadlock 

occurs  in  this 

system  when 

one  unit  of  the 

resource  has 

been  allocated  to 

each  process 

and  each  process 

requests  one  more  unit.  This  situation  occurs  in  system  state 
S33.  State  S33  is  a  total  deadlock  state,  because  both 
processes  are  deadlocked  in  S33,  In  Figure  2,2  we  can  tell 
that  S33  is  a  total  deadlock  state  because  no  edges  are 

i 

directed  away  from  node  S33. 

Since  deadlock  state  S33  can  be  reached  from  any  other 
state  there  are  no  safe  states  in  the  system. 
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holds  0,  holds  0,  holds  1,  holds  1,  holds  2, 
needs  0  needs  1  needs  0  needs  1  *needs  0 


PI  holds  0, 
needs  0 


PI  holds  0/ 
needs  1 


PI  holds  1  , 
needs  0 


PI  holds  1 , 
needs  1 


PI  holds  2, 
needs  0 


Figure  2^2  A  system  with  two  processes  and  a  resource  of  two 


identical  units. 
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2.4  Deadlock  Strategies 

In  any  computer  system  where  processes  share  resources  or 
pass  signals,  there  must  be  a  strategy,  stated  or  not  stated, 
to  handle  the  problem  of  deadlock.  We  can  characterize  these 
strategies  as  belonging  to  one  of  the  following  classes: 

Prevention.  The  system  is  designed  so  that  deadlock  is 
not  possible,  that  is,  the  system  is  designed  so  that  it 
is  safe.  A  system  which  is  not  safe  can  sometimes  be  made 
safe  by  prohibiting  operations  which  may  lead  to  deadlock. 
Ha  vender’s  policy  of  ordered  resources  and  Haberraann’s 
policy  rsing  maximum  claims  (see  Section  3.9)  are  examples 
of  deadlock  prevention  strategies. 

I}£bection._  Deadlocks  can  occur,  but  they  are  detected  by 
the  system.  When  a  deadlock  is  detected,  the  system  can 
’’recover"  from  the  deadlock  by  terminating  deadlocked 
processes  or  by  pre-empting  resources  from  blocked 
processes. 1  This  strategy  may  allow  much  higher  resource 
utilization  than  is  possible  when  deadlock  is  absolutely 
prevented,  and  it  should  be  used  when  deadlock  is  not  too 
frequent  and  recovery  is  not  too  costly.  The  algorithms 
given  in  Chapters  3  and  4  should  make  deadlock  detection 
practical  in  many  cases  where  deadlock  goes  undetected  in 
current  systems.  This  strategy  has  not  yet  been  used 
widely,  but  it  offers  the  distinct  advantage  of  a  "soft 
fail"  over  the  next  strategy. 

Crash.  Deadlocks  are  possible  and  go  undetected  by  the 
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system.  It  is  the  responsibility  of  the  operator  both  to 
decide  that  a  deadlock  has  occurred  and  to  take  steps  to 
remove  the  deadlock.  One  might  name  this  the  "no  strategy 
strategy.”  However,  this  name  is  a  bit  too  unkind  because 
this  strategy  saves  the  time  and  space  required  by 
deadlock  prevention  and  detection  algorithms. 

The  methods  of  handling  the  deadlock  problem  which  are 
discussed  in  succeeding  chapters  are  all  prevention  or 
detection  strategies. 

On  Harmonious  Cooperation 


Without 

formalizing 

t  he 

ideas  of 

time  and  of 

the 

finishing  of 

a  process,  we 

state 

the  follow 

ing  theorem. 

Th  e  Harm 

onious  Cooper 

at  ion 

Theorem . 

Suppose  that 

the 

system  contains  a  finite  number  of  processes,  that  each 
process  executes  only  a  finite  number  of  operations  before 
finishing,  and  that  each  operation  in  a  process  which  is 
not  blocked  is  executed  in  finite  time.  Then  all 
processes  will  finish  if  and  only  if  deadlock  does  not 
occur. 

The  proof  fellows  from  the  observations  that  (1)  as  long  as  at 
least  one  process  is  not  deadlocked,  operations  will  continue 
to  be  executed,  and  that  (2)  there  are  only  a  finite  number  of 
operations  among  all  the  processes  which  can  be  executed 
before  all  processes  finish. 

Given  a  system  with  a  finite  number  of  processes,  each  of 
which  finishes  after  a  finite  number  of  operations,  the 
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res  us  that  if  deadlock  is  tested  for  and  not 
if  the  system  begins  in  a  safe  state,  then  all 
11  finish.  Thus,  in  a  system  of  this  type,  an 
adlock  is  necessarily  a  true  deadlock-  We  have 
the  Harmonious  Cooperation  Theorem  because 
Haberniann  say  a  set  of  processes  "cooperate 
when  all  are  guaranteed  to  finish, 
not  include  in  the  hypothesis  of  the  theorem  the 
ns  that  (1)  there  is  a  finite  number  of  processes 
each  process  will  only  execute  a  finite  number  of 
efore  finishing,  then  we  are  left  with  the  much 
sion : 

as  deadlock  does  not  occur,  operations  will 
to  be  executed. 

conclusion  insures  us  only  that  if  deadlock  is 
d  not  detected,  or  if  the  system  begins  in  a  safe 
work  is  continually  being  done  by  the  system. 

t 

ther  of  the  two  assumptions  is  not  true,  it  is 
have  an  effective  deadlock  which  is  not  a  true 


These  two  assumptions  may  or  may  not  be  realistic  in  a 
practical  system  as  we  illustrate  in  the  following  examples: 

Example  _1  Both  of  these  assumptions  are  satisfied  in  a 
system  which  starts  cold  at  8:00  a.m.,  accepts  user  jobs 
until  4:00  p.m.,  and  then  continues  computing  until  the 
last  job  finishes.  The  theorem  assures  us  that,  given 
time,  all  jobs  in  this  system  will  finish;  however,  notice 
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that  it  does  not  tell  us  anything  about  the  order  of 
finishing  or  about  system  efficiency.  Although  order  of 
finishing  and  system  efficiency  are  very  important,  we 
will  continue  to  confine  our  attention  to  the  more 
fundamental  issue:  Do  the  jobs  finish  at  all? 

Example  2  If  the  system  runs  night  and  day,  accepting  new 
jobs  all  the  while,  the  assumption  of  a  finite  number  of 
processes  is  not  satisfied,  and  we  are  not  necessarily 
guaranteed  that  all  jobs  will  finish.  In  this  situation, 
a  job  with  low  priority  and  a  large  resource  request  could 
experience  effective  deadlock  and  never  finish.  Still,  we 
are  left  with  the  consolation  that  if  at  any  time  no  more 
jobs  are  accepted,  or  there  is  a  long  enough  time  between 
job  arrivals,  then  all  jobs  in  the  system  will  finish 
(assuming  deadlock  does  not  occur) . 

Ex  ample  J  Among  system  processes,  such  as  spooling 
routines,  the  assumption  that  there  is  a  finite  number  of 
operations  in  each  process  may  be  violated.  It  is 
convenient  to  write  a  spooling  routine  as  a  cyclic  program 
which  never  finishes.  If  a  finite  length  process  competes 
for  resources  with  cyclic  processes,  it  is  possible  that 
the  finite  length  process  will  never  finish,  although  it 
never  experiences  a  true  deadlock. 

(See  [Holt  1971]  for  other  examples  in  which  effective 
deadlock  is  not  true  deadlock.) 

In  summary,  the  strategies  of  deadlock  prevention  and 
detection  help  us  ensure  that  processes  in  a  computer  system 
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CHAPTER  3.  IMPLICIT  INTERACTION  OF  PROCESSES 

In  Chapters  3,  4,  and  5  we  will  investigate  the  sources 
of  deadlock  among  processes  which  request,  acquire,  and 
release  resources.  We  will  use  the  term  "resource"  in  a  very 
broad  sense;  a  resource  will  be  anything  which  a  process  can 
request  or  wait  for,  he  it  a  physical  device,  a  message,  or  a 
signal.  (This  interpretation  of  the  terra  has  been  used  by 
Shaw  [1971]  and  Weiderman  [1971].)  In  this  chapter  we  will 
investigate  reusable  resources  (which  behave  like  physical 
devices) ;  in  Chapter  4  we  will  investigate  consumable 
resources  (which  behave  like  messages) ;  and  in  Chapter  5  we 
will  investigate  both  types  of  resources  together. 

The  most  important  new  material  in  this  chapter  is  an 
intuitively  simple  graph  model  of  processes  sharing  reusable 
resources  together  with  fast  algorithms  for  detecting  and 
preventing  deadlock. 

i 

3.1  Reusable  and  Consumable  Resources 

Reusable  Resources 

A  reusable  resource  is  a  set  of  identical  units  which  can 
be  requested  by  processes  in  a  computing  system.  Following  a 
request  a  process  must  wait  until  enough  units  are  available 
to  satisfy  its  request;  then  the  process  acquires  the 
requested  units.  At  some  later  time  the  process  can  release 


units  which  it  has  acquired 


Each  reusable  resource  has  the 
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following  properties: 

There  is  a  fixed  total  number  of  units  of  the  resource* 
Each  unit  of  the  resource  either  is  available  (not 

allocated)  or  has  been  acquired  by  (allocated  to)  a 
particular  process.  A  particular  unit  or  a  resource  can  be 
allocated  to  at  most  one  process  at  a  time.  A  process  can 
release  a  unit  of  a  resource  only  if  the  process  has 
acquired  but  not  yet  released  that  unit.  Units  can  not  be 
pre-empted;  once  a  process  has  acguired  a  unit,  the  unit 
will  not  become  available  until  released  by  the  process. 
(The  term  “reusable  resource”  has  been  borrowed  from  the  term 
“serially  reusable  resource”  used  in  IBM  literature  [ IBM 
1968a,  Havender  1968],  Murphy  [1968]  and  Russell  [1970] 

investigate  reusable  resources  whose  units  can  be  allocated  to 
more  than  one  process  at  a  time.)  We  will  now  give  examples 
of  reusable  resources. 

Example  _1 «_  The  physical  devices  of  the  computer 
system,  such  as  channels,  core,  tape  drives,  drums,  and 
disks  can  be  reusable  resources.  The  units  of  some  of 
these  resources  will  depend  on  the  allocation  strategies 
of  the  computer  system;  for  example,  disks  may  be 
allocated  in  units  of  tracks,  or  cylinders,  or  even  entire 
disks. 

Example  2.  Certain  information  structures  shared  by 
processes,  such  as  records  in  a  data  set  and  linkage 

pointers  for  buffer  pools,  are  reusable  resources.  The 

processes  must  request,  acquire. 


and  release  access  to 
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these  information  structures  to  guarantee  that  the 
structures  can  be  inspected  or  updated  without 
interference  from  other  processes. 

Example  Dijkstra  has  written  about  the  "mutual 
exclusion"  problem,  which  is  the  problem  of  guaranteeing 
that  at  most  one  process  at  a  time  gains  access  to  a 
"critical  section"  [1965a].  A  process  enters  its  critical 


section 

to  inspect 

or  update 

information 

structures 

without 

interference 

from  other 

processes. 

A  critical 

section 

is  logically 

equivalent 

to  a  reusab 

le  resource 

with  a  single  unit  which  must  be  requested,  acquired,  and 
released. 


The  above 

examples 

illustrate 

the  fact  that 

reusable 

resources  can 

be  either 

physical 

devices  or  inf 

orma  tion 

structures. 

Consumable  Resources 


A  consumable  re  source  is  a  set  of  identical  units  which 
can  be  Requested  by  processes  in  a  computing  system. 
Following  a  request,  a  process  must  wait  until  enough  units 
are  available  to  satisfy  its  request;  then  the  process 
acquires  the  requested  units.  Once  a  unit  of  a  consumable 
resource  has  been  acquired  by  a  process,  that  unit  ceases  to 
exist,  i.e.,  the  process  "consumes"  the  unit.  Associated  with 


each  consumable  resource  is  a  subset  of  the  processes  called 
the  producers  cf  that  resource;  only  the  producers  can  release 
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units  of  the  resource.  (Requesting  and  acquiring 
1  for  reusable  and  consumable  resources,  but 
different.)  Each  consumable  resource  has  the 
perties: 

no  fixed  total  number  of  units  of  the  resource, 
it  of  the  resource  is  available^  if  a  unit  is 
ty  a  process,  the  unit  ceases  to  exist.  Only  a 
which  is  a  producer  of  the  resource  can  release 
the  resource;  a  producer  is  allowed  to  release 
er  of  units  of  the  resource  at  any  time  (assuming 
ucer  is  not  blocked  waiting  to  acquire  units 
a  request).  Any  released  units  immediately 
ailable. 


some  examples  of  consumable  resources. 


Example  _U  The  card  reader  produces  (releases)  card 
images  which  are  consumed  (requested  and  acquired)  by  some 
process,  probably  the  input  spooling  process.  Thus,  card 
images  are  a  consumable  resource. 

Example  2_.  In  many  systems,  external  interrupts  are 
received  by  a  special  interrupt  handling  process  which 
interprets  the  interrupt  and  passes  a  special  type  of 
message  to  another  process  which  is  waiting  to  consume 
that  type  of  message.  The  interrupt  handling  process  then 
cycles  back  to  wait  for  the  next  external  interrupt.  The 
interrupt  handling  routine  consumes  the  external 
interrupts  and  produces  messages  of  various  types.  Thus, 
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rrupts  and  the  various  types  of  messages 
curces. 

difference  between  reusable  and 
is  that  the  units  of  a  reusable  resource 
estroyed,  but  only  passed  (requested  and 
of  available  units  to  a  process  and  then 
d)  to  the  pool  of  available  units-  By 

a  consumable  resource  are  created 
eased)  and  destroyed  (“consumed” ,  or 
)- 

In terac  tions 


As  the  system  changes  states,  the  set  of  processes  which 
can  release  a  consumable  resource  does  not  change,  i.e-  the 
set  of  producers  is  fixed.  By  contrast,  the  set  of  processes 
which  can  release  a  reusable  resource  will  change  as  units  are 
acquired  and  released. 

We  say  consumable  resources  cause  explicit  interactions 
among  the  processes,  because  the  designer  of  a  process  knows 
in  advance  that  a  request  for  a  consumable  resource  can  cause 
a  wait  for  releases  by  a  fixed  set  of  processes  (the  producers 
of  the  resource).  In  practical  systems  it  is  often  the  case 
that  a  consumable  resource  (a  set  of  messages)  is  produced  by 
a  process  expressly  for  another  particular  process. 

We  say  reusable  resources  cause  implicit  interactions 
among  the  processes,  because  the  designer  of  a  process  does 
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3.2  Graph  Theory  —  Some  Definitions 

3efore  investigating  systems  in  which  processes  request, 
acquire,  and  release  resources,  we  need  some  definitions  from 
the  theory  of  directed  graphs. 

We  define  a  directed  praph  as  a  pair  (Q,  E)  where  Q  is  a 
nonempty  set  of  nodes  and  E  is  a  set  of  directed  edges  (or 
simply  edqesj_i  Each  edge  in  E  is  an  ordered  pair  (a,b)  where 
a  and  b  are  nodes  in  Q.  An  edge  (a,b)  is  said  to  be  directed 
from  node  a  and  directed  to  node  b.  For  example,  a  directed 
graph  could  consist  of  a  set  Q  of  four  nodes  (a,b,c,d}  and  a 
set  E  of  five  edges  { (a ,  b)  ,  (a,  b)  ,  (a,  c)  ,  (c,  d)  ,  (d ,  c) }  .  This 
graph  is  pictured  in  Figure  3.1. 

If  a  node  has  no  edges  directed  to  it,  it  is  called  a 
source^  if  it  has  no  edges  directed  from  it,  it  is  called  a 
sink;  if  it  has  no  edges  directed  to  or  from  it,  it  is  called 
an  isolated  iiode.  In  Figure  3.1,  node  a  is  a  source,  node  b 
is  a  sink,  and  there  is  no  isolated  node.  If  the  graph 
contains  edge  (a,b),  then  we  say  node  b  is  a  son  of  node  a, 
and  we  say  a  is  a  father  of  node  b.  A  path  is  a  sequence 
(a, b,c, . . . , r, s)  containing  at  least  two  nodes  where  (a,b), 
(b,c),  and  (r,s)  are  edges;  a  path  (a,  b,  c , . . .  ,  r ,  s)  is 
said  to  be  directed  from  a  and  directed  to  s.  In  Figure  3.1, 
c  is  a  sen  of  a,  d  is  a  son  of  c,  and  (a,c,d)  is  a  path 
directed  from  a  to  d.  A  cycle  is  a  path  whose  first  and  last 
nodes  are  the  same;  in  Figure  3.1  (c,d,c)  is  a  cycle. 

A  directed  graph  (Q, E)  is  said  to  be  bipartite  if  its 


set 
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of  nodes  Q  can  be  partitioned  into  two  disjoint  subsets  PI  and 
RHO  such  that  for  every  edge  (a,b)  in  E,  either  a  is  in  PI  and 
b  is  in  RHO  or  a  is  in  RHO  and  b  is  in  PI.  The  directed  graph 
in  Figure  3.1  is  bipartite  because  Q  can  be  partitioned  into 
P 1=  { a ,  d }  and  RHO={b,c}.  (Definitions  similar  to  the  above 
definitions  are  well  known  in  graph  theory.  See  [ Berge 
1958  ], for  example.) 

If  a  directed  graph  has  at  most  one  edge  (a,b)  directed 
from  a  given  node  a  to  a  given  node  b  then 

(1)  there  are  at  most  N2  edges  in  E  where  N  is  the  number 
of  nodes  in  Q,  and 

(2)  if  the  graph  is  bipartite  then  there  are  at  most  2nra 
edges  in  E  where  n  and  m  are  the  numbers  of  nodes  in  PI 
and  RHO ,  respectively. 

These  two  observations  are  easily  verified  from  the  above 
definitions. 

Knots 


The  Piocjeny  of  a  node  a  is  the  set  of  all  nodes  b  such 
that  there  is  a  path  directed  from  a  to  b.  A  knot  is  a 
nonempty  set  K  of  nodes  such  that  for  each  node  a  in  K,  the 
progeny  of  a  are  exactly  set  K.  In  Figure  3.1  set  {c,d}  is  a 
knot  because  the  progeny  of  both  c  and  d  is  set  (c,d). 

Lemma  3.1  Knots  have  the  following  properties: 

(1)  If  a  directed  graph  contains  a  knot,  then  it  contains 

a  cycle. 

(2)  No  node  in  a  knot  is  a  sink. 
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(3)  No  path  is  directed  from  a  node  in  a  knot  to  a  sink. 

(4)  A  directed  graph  does  not  contain  a  knot  if  and  only 
if  for  every  node,  either  the  node  is  a  sink  or  a  path  is 
directed  from  the  node  to  a  sink. 

Proof  Fart  (1)  is  true  because  each  node  in  a  knot  is  one 
of  its  own  progeny.  Part  (2)  is  true  because  a  sink  has 
no  progeny  and  a  node  in  a  knot  must  have  at  least  itself 
among  its  progeny.  Part  (3)  is  true  because  all  progeny 
of  a  node  in  a  knot  are  also  in  the  knot,  but  by  part  (b) 
a  sink  cannot  be  in  a  knot. 

Now  we  prove  (4).  First  we  show  that  if  there  is  no 
knot  then  every  node  is  a  sink  or  has  a  path  directed  from 
it  to  a  sink.  Let  us  introduce  the  notation  P (a)  to 
represent  the  progeny  of  node  a.  It  is  easily  shown  that 
if  node  a2  is  in  P(al)  then  P  (a2)  is  a  subset  of  P(al). 
For  any  node  al  which  is  not  in  a  knot,  either  P(al)  is 
empty  or  there  must  exist  node  a2  in  P(al)  such  that 
P(a2)*P(a1);  necessarily,  P{a2)  is  a  strict  subset  of 
P(al).  Similarly,  if  a2  is  not  in  a  knot  then  either 
P(a2)  is  empty  or  there  exists  a3  in  P{a2)  such  that  P(a3) 
is  a  strict  subset  of  P(a2) ,  and  so  on  for  a4,  a5,  ..., 
ai,  until  for  ai,  P (ai)  is  empty.  Thus,  ai,  which  is  in 


P(al),  is 

a  sink. 

Hence,  if  the 

graph  contains 

no  knot 

then  for 

any  node 

ai,  either  ai 

is  a  sink  or  a 

path  is 

directed  from  ai  to  a  sink.  Finally,  we  show  that  if 
there  is  a  knot  then  some  node  which  is  not  a  sink  does 
not  have  a  path  leading  from  it  to  a  sink.  This  follows 
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im  mediate  Ly , 
node  (in  a 
from  which  no 


because  if  there  is 
knot)  which  is  not  a 
path  is  directed  to  a 


a  knot  then  there 
sink  (by  part  (2) 
si nk  (by  part  (3) ) 


is  a 
and 


i 

Figure  An  example  of  a  directed  graph, 

is  a  source,  b  is  a  sink,  sequence  (c,d,c) 
[c,d]  is  a  knot. 


SECTION  3.2  44 
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a 

In  this  example  a 
is  a  cycle,  and  set 
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3.3  Reusable  Resource  Systems 

In  this  section  we  define  a  formal  graph  model  of  systems 
of  processes  whose  only  interactions  are  via  reusable 
resources.  While  this  graph  model  is  equivalent  to  the  matrix 
model  yiven  by  Shoshani  [  1969a  ]r  it  was  developed 
independently  by  the  author  of  this  thesis.  We  define: 

A  reusable  resource  system  is  completely  characterized  by 

(1)  a  nonempty  set  of  processes  PI=  {P 1 , P2 , - - . , Pn} , 

(2)  a  nonempty  set  of  reusable  resources 

RHO=  {R  1  ,R  2  ,  .  .  .  ,  Rm)  ,  and 

(3)  for  each  reusable  resource  Rj,  a  strictly  positive 

integer  tj,  called  the  total  units  of  Rj. 

In  this  chapter  the  only  type  of  resources  will  be  reusable 
resources,  so  they  will  be  called,  simply,  resources. 

Reusable  Resource  Graphs 

Each  state  of  a  reusable  resource  system  is  represented 
by  a  bipartite  graph,  which  is  called  a  reusable  resource 
graph.  The  disjoint  sets  of  nodes  of  the  bipartite  graph  are 
PI=  {Pi , P2 . - , Pn}  and  RHO=  {R  1 , R2 , . . . , Rm) .  Each  edge  directed 
from  a  process  node  Pi  to  a  resource  node  Rj  is  called  a 
request  edge  and  represents  a  request  by  process  Pi  for  one 
unit  of  resource  Rj.  Each  edge  directed  from  a  resource  node 
Rj  to  a  process  node  Pi  is  called  an  assignment  edge  and 
represents  the  fact  that  process  Pi  has  acquired  {but  not  yet 
released)  a  unit  of  resource  Rj.  Associated  with  each 
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resource  node  Rj  is  a  nonnegative  integer  rj,  rj  <  tjr  whose 
value  is  the  number  of  available  units  of  Rj. 

Proceeding  more  formally,  the  set  of  states  SIGMA  of  a 
reusable  resource  system  is  the  set  of  all  reusable  resource 
graphs  for  the  system.  We  define: 

A  reusable  resource  graph  is  any  bipartite  directed  graph 
whose  disjoint  sets  of  nodes  are  PI= {P 1 , P2 , - . . , Pn}  and 
RHO  =  {R1 ,R2,.. . ,Rm}  ,  together  with  an  available  units 
vector  (r  1  ,r2  r.  .  -  ,  rm)  such  that 


(1)  for  a  given  resource  node  Rj,  the  number  of  assignment 
edges  directed  from  P.j  does  not  exceed  tj, 

(2)  each  element  rj  of  the  available  units  vector  is  equal 
to  tj  minus  the  number  of  assignment  edges  directed  from 
R j ,  and 

(3)  for  a  given  process  node  Pi  and  a  given  resource  node 
R j ,  the  number  of  request  edges  (Pi,Rj)  plus  the  number  of 
assignment  edges  (Rj,Pi)  does  not  exceed  tj. 

t 

(rj,  which  gives  the  available  units  of  resource  Rj,  is 
redundant  because  it  is  completely  determined  by  the  total 
units  tj  and  the  number  assignment  edges  directed  from  Rj.  We 
include  rj  in  the  definition  of  the  state  only  to  make 
subsequent  explanations  simpler.)  Requirement  (3)  in  the 
definition  means  that  a  process  can  not  acguire  and  request 
more  than  the  total  units  of  a  resource. 

Figure  3.2  gives  an  example  of  a  state  of  a  reusable 
resource  system.  In  the  figure,  square  nodes  represent 
process  nodes  and  round  nodes  represent  resource  nodes.  We 
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have  illustrated  the  fact  that  resource  R1  has  two  total  units 
(t1=2)  by  drawing  two  "subnodes”  inside  the  node  for  Hi;  each 
assignment  edge  is  drawn  starting  at  a  subnode-  Thus  the 
number  of  available  units  is  the  number  of  subnodes  which  do 
not  have  assignment  edges,  drawn  from  them-  In  the  figure  the 
available  units  are  rl-1  and  r2=0.  These  subnodes  are  not 
included  in  the  formal  definition  of  reusable  resource  graphs 
and  we  show  them  only  as  a  convenient  way  to  picture  the  total 
units  vector  and  the  available  units  vector. 

Operations  in  a  Reusable  Resource  System 


The  processes  in  a  reusable  resource  system  are  partial 
functions  from  system  states  into  subsets  of  system  states;  we 
will  specify  these  partial  functions  by  describing  the 
operations  the  processes  can  execute.  There  are  three  types 
cf  operations:  requests,  acquisitions,  and  releases. 
Essentially,  the  reusable  resource  graph  (system  state)  is 
changed  (a)  by  a  request  operation  to  have  more  request  edges, 
(b)  by  an  acquisition  operation  to  have  less  request  edges, 
more  assignment  edges,  and  less  available  units,  and  (c)  by  a 
release  operation  to  have  less  assignment  edges  and  more 
available  units.  For  system  states  S  and  T,  we  define: 

Requests.  In  state  S  if  no  request  edges  are  directed 
from  node  Pi,  then 


S  —  i->  T 


where  S  and  T  are  identical  except  that  in  T  there  are 
request  edges  directed  from  node  Pi. 


SECTION  3.3 


48 


tions_.  In  state  S  if  there  are  request  edges 
directed  from  node  Pi,  and  for  each  resource  Rj,  rj  is  as 
large  a; 

Rj  ,  then 


Pi,  then 


the 

n 

umbe  r 

of 

request 

edges  d 

irecte 

d  from  Pi  to 

S  -i-> 

T 

and 

T 

are 

id 

ent ical 

except 

that 

(a)  for  each 

Rj/ 

r  j 

is  decre 

ased  by 

one  for 

each 

request  edge 

rom 

Pi 

to  Rj 

/  a 

n  d  ( b ) 

each  req 

uest  e 

dge  directed 

delet 

ed. 

In 

st  ate 

S 

if  no 

request 

edges 

are  directed 

Pi 

/ 

and  some 

assign 

ment  edg 

es  are 

directed  to 

S  -  i-  > 

T 

and 

T 

are 

id 

entical 

except 

that 

some  of  the 

assignment  edges  directed  to  Pi  are  deleted,  and  for  each 
assignment  edge  (Rj,Pi)  deleted,  rj  is  increased  by  1. 

We  could  also  define  a  null  operation  which  would  cause  no 

i 

change  in  the  system  state  and  could  be  executed  by  process  Pi 
any  time  node  Pi  has  no  reguest  edges  directed  from  it.  This 
operation  would  model  any  activity  by  a  process  other  than  the 
requesting,  acquiring,  and  releasing  of  units.  We  do  not 
include  the  null  operation  simply  because  it  would  have  no 
effect  on  our  investigation  of  deadlock. 

See  Figure  3.3  for  examples  of  operations.  As  can  be 
seen  in  the  figure  an  operation  by  process  Pi  changes  only 
edges  directed  to  or  from  node  Pi. 

From  the  definitions  of  these  operations  and  the 
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definition  of  "blocked"  in  Section  2.2,  it  is  easily  shown 
that : 


Process  Pi 

is 

blocked 

if  and  only  if  there  is  a 

resource 

node 

Rj  such 

that  the  number  of  request  edges 

directed 

from 

Pi  to 

Rj 

exceeds 

the  available  units  rj  of 

resource 

Rj. 

Tha 

t  is. 

the  on 

iy 

time  a 

process  is  blocked  is  when 

it  has  a 

reg 

ues  t  f 

or  more 

uni 

ts  than 

are  presently  available. 
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PI 


R2 


Figure  3^2  Example  of  a  system  state  in  a  reusable  resource 
system.  The  total  units  vector  is  (2,1)  and  the  available 
units  vector  is  (1,0).  Process  Pi  has  been  allocated  one  of 
the  two  units  of  HI.  Process  P2  has  been  allocated  the  one 
unit  of  R2  and  has  requested  both  units  of  PI. 


State  S  -1->  State  T  -1->  State  U  -1->  State  V 


PI  □ 


P  2  □ 


P2  □ 


PI 


R  1 


V 

P  2  □ 


Figure  3^3  Examples  of  operations  in  a  reusable  resource 
system.  The  system  has  two  processes  and  a  resource 
contain ing  three  total  units.  One  unit  of  tne  resource  has 
been  allocated  to  process  P2.  Process  ?1  first  requests  two 
units  of  the  resource,  then  acquires  the  two  units,  and 
finally  releases  one  of  the  two  units. 
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3.4  Graph  Reductions  and  Deadlock 

In  this  section  we  develop  a  necessary  and  sufficient 
condition  for  deadlock  in  a  reusable  resource  system.  This 
condition  will  be  given  in  terms  of  manipulations  of  the 
reusable  resource  graph.  Each  manipulation,  called  a 
reduction,  deletes  some  of  the  edges  in  the  reusable  resource 
graph;  the  original  state  is  not  a  deadlock  state  if  and  only 
if  a  sequence  of  reductions  deletes  all  edges  in  the  graph. 
We  define  reductions  as  follows: 

A  reusable  resource  graph  can  be  reduced  by  any  process 
node  Pi  which  is  not  an  isolated  node  and  which  is  not 
blocked.  The  reduction  by  Pi  deletes  all  edges  directed 
to  or  from  Pi;  for  each  assignment  edge  (Rj,Pi)  deleted, 
rj  is  increased  by  1.  We  say  the  reusable  resource  graph 
is  completely  reducible  if  and  only  if  a  sequence  of 
reductions  deletes  all  edges  in  the  graph. 

A  reduction  by  Pi  is  equivalent  to  an  acquisition  operation  by 
Pi  (if  Pi  has  a  request  pending)  followed  by  a  release 
operation  in  which  Pi  releases  all  units  assigned  to  it. 
Thus,  a  reduction  of  a  reusable  resource  graph  always  results 
in  another  reusable  resource  graph. 

Notice  that  a  sequence  of  reductions  can  include  a 
particular  process  Pi  only  once  because  (a)  reducing  by  Pi 
leaves  Pi  as  an  isolated  node,  and  (b)  it  is  not  allowed  to 
reduce  by  an  isolated  process  node. 

of  "completely  reducible"  requires  that 


The 


def init ion 
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the  sequence  of  reductions  delete  all  edges.  This  is 
equivalent  to  requiring  that  the  sequence  leave  all  processes 
not  blocked,  because  once  all  processes  are  not  blocked,  the 
graph  can  be  reduced  by  all  process  nodes  which  are  not 
isolated  nodes,  thereby  deleting  all  edges. 

The  following  lemma  implies  that  the  order  of  reductions 
of  a  state  is  not  important  in  that  the  same  reductions  will 
be  possible,  regardless  of  which  are  done  first. 

Lemma _ 3^2  Any  sequence  of  reductions  of  a  reusable 

resource  graph  leads  to  a  unique  reusable  resource  graph 
which  can  not  be  reduced. 

E£2°£  The  lemma  will  be  proved  using  the  following  two 
propositions. 

Proposition  1.  If  state  S  is  reduced  by  two  different 
sequences  which  contain  the  same  processes  (in 
different  orders) ,  then  both  sequences  reduce  S  to  the 
same  state. 

i 

Proposition  1  is  true  because  a  reduction  by  any  process 
Pi  deletes  exactly  the  same  edges  (edges  directed  to  and 
from  node  Pi) ,  regardless  of  what  reductions  precede  the 
reduction  by  Pi. 

Proposition  2.  If  state  S  can  be  reduced  by  a  process 
numbered  i  and  S  is  reduced  by  a  sequence  of  processes 
(which  does  not  include  process  i)  to  state  T,  then 
state  1  can  be  reduced  by  process  i. 

Proposition  2  is  true  because  reductions  can  only  increase 
(never  decrease)  the  available  units. 
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We  now  prove  Lemma  3-2-  Let  us  assume  that  state  S 
is  reduced  by  seguence  SEQ1  to  Tl  and  that  state  S  is 
reduced  by  seguence  SEQ2  to  T2r  where  states  Tl  and  T2  can 
not  be  reduced.  We  will  assume  that  Tl  *  T2  and  show  that 
this  results  in  a  contradiction-  Let  the  numbers  of  the 
processes  in  SEQ1  be  (il, i2,« • • ,ix) •  Since  Tl  #  T2,  by 
Proposition  1  it  must  be  that  sequence  SEQ 1  contains  a 
process,  let  its  number  be  iu,  which  is  not  contained  in 
5EQ2  (or  else  SEQ2  contains  a  process  not  in  SEQ1 ) . 
Clearly  iu  is  not  il,  because  if  iu  =  il  and  iu  is  not  in 
SEQ2,  then  by  Proposition  2  it  would  be  possible  to  reduce 
state  12  by  process  iu,  and  by  assumption,  T2  can  not  be 
reduced.  Hence,  iu  *  il,  and  il  must  be  in  seguence  SEQ2- 
We  now  show  that  iu  *  i2.  We  know  il  is  in  SEQ2  and  thus 
the  available  units  in  T2  must  be  at  least  as  large  as  the 
available  units  after  S  has  been  reduced  only  by  process 
il.  But  once  S  is  reduced  by  il,  then  a  reduction  by  i2 
is  possible,  and  hence  if  SEQ2  contains  il  but  not  i2,  it 
must  be  that  T2  can  be  reduced  by  i2.  By  assumption,  T2 
can  not  be  reduced  and  thus  iu  *  i2,  and  i2  must  be  in 
SEQ2-  By  similar  reasoning  it  can  be  shown  that  iu  #  i3, 
iu  *  i4,  ---,  iu  *  ix.  Hence,  SEQ1  can  not  contain  a 
process  iu  unless  iu  is  also  in  SEQ2-  Similarly,  SEQ2  can 
not  contain  a  process  unless  that  process  is  also  in  SEQ 1 • 
Hence,  SEQ1  and  SEQ2  contain  the  same  processes  and  by 
Proposition  1  it  must  be  that  Tl  -  T2-  We  assumed  Tl  *  T2 
and  derived  the  contradiction  that  Tl  =  T2.  Thus,  it  must 
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be  that  T1  —  T2,  and  therefore,  any  sequence  of  reductions 
of  any  state  S  must  lead  to  a  unique  state  which  can  not 
be  reduced. 

Necessary  and  Sufficient  Conditions  for  Deadlock 

We  now  state  the  necessary  and  sufficient  conditions  for 
the  deadlock  of  a  particular  process. 

Theorem _ 3.  1  Process  Pi  is  not  deadlocked  if  and  only  if  a 

sequence  of  reductions  leaves  a  state  in  which  Pi  is  not 
blocked. 

Suppose  a  sequence  of  reductions  of  state  S  leaves 
state  T  in  which  Pi  is  not  blocked.  Since  a  reduction  by 
any  process  Pj  is  equivalent  to  an  acquisition  by  Pj 
followed  by  a  release  by  Pj  (or  just  a  release  by  Pj)  then 
the  sequence  of  reductions  can  be  realized  by  a  sequence 
of  acquisitions  and  releases.  Thus  S  -*->  T ,  where  Pi  is 
not  blocked  in  T,  and  therefore  Pi  is  not  deadlocked  in  S. 

t 

Now  suppose  that  every  sequence  of  reductions  leaves 
Pi  blocked.  By  Lemma  3.2  all  these  sequences  lead 
eventually  to  a  unique  state  T;  in  T  process  Pi  and 
possibly  ether  processes  are  blocked.  Any  processes  not 
blocked  in  T  have  released  (via  reductions)  all  units 
which  were  assigned  to  them  in  S,  and  thus  cannot  release 
more  units  no  matter  what  operations  they  execute.  Hence, 
no  process  blocked  in  T  can  have  enough  units  available  to 
acquire  its  requested  units  until  some  other  process 
blocked  in  T  releases  some  units.  Thus,  for  any  state  U 
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such  that  S  -*->  U,  the  processes  blocked  in  T  will  always 
be  blocked.  Hence  Pi  is  deadlocked  in  S. 

Extending  this  theorem  to  apply  to  all  processes  we  have: 

Corollary _ 3_. J  A  reusable  resource  graph  is  not  a  deadlock 

state  if  and  only  if  it  is  completely  reducible. 

Pro of  If  the  graph  is  completely  reducible,  then  by 
Theorem  3.1,  no  process  is  deadlocked,  and  the  graph  is 
not  deadlocked.  If  the  graph  is  not  completely  reducible 
then  all  sequences  of  reductions  lead  to  a  unique  graph  T 
in  which  some  processes  are  blocked.  Processes  blocked  in 
T  will  be  blocked  after  any  sequence  of  operations. 
Hence,  these  processes  are  deadlocked  in  the  original 
state. 

Recall  from  Section  2.2  that  a  process  is  not  deadlocked 
if  and  only  if  there  exists  a  sequence  of  operations  which 
leaves  the  process  not  blocked.  Essentially,  a  sequence  of 
reductions  will  ”findM  a  sequence  of  operations  which  will 
leave  any  given  process  not  blocked,  if  such  a  sequence  of 
operations  exists.  Given  that  such  a  sequence  of  operations 
exists,  by  definition  the  process  in  question  is  not 
deadlocked.  However,  the  existence  of  such  a  sequence  of 
operations  does  not  imply  that  the  process  in  question  will 
actually  become  not  blocked;  the  only  implication  is  that  it 
is  possible  for  the  process  to  become  not  blocked. 

Figure  3.4  gives  examples  of  reductions.  In  the  figure, 
state  s  is  not  a  deadlock  state  because  the  reductions  delete 
all  edges  in  the  graph. 
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From  Theorem  3.  1  it  is  easy  to  prove  that  each  deadlock 
must  involve  at  least  two  processes.  If  we  assume  that  only 
one  process  in  a  state  is  deadlocked,  then  necessarily  a 
sequence  of  reductions  can  cause  all  other  processes  to 
release  their  resources;  at  that  point  the  supposedly 
deadlocked  process  is  no  longer  blocked.  Thus  a  single 
deadlocked  process  cannot  be  deadlocked,  and  hence  it  takes 
two  processes  to  "cause"  a  deadlock. 

Cycles  and  Knots 

when  a  process  is  deadlocked,  no  sequence  of  operations 
can  make  that  process  not  blocked.  One  might  ask  what  type  of 
configuration  in  a  reusable  resource  graph  prevents  processes 
from  ever  becoming  not  blocked.  Intuitively,  we  suspect  that 
deadlock  occurs  when  a  process  waits  for  resources  held  by 
another  process,  which  waits  for  resources  held  by  another 
process,  and  so  on  until  the  last  process  in  the  sequence 
waits  for  resources  held  by  the  first.  Thus,  we  suspect  that 
deadlock  occurs  when  a  process  waits,  perhaps  in  some  indirect 
manner,  for  itself.  That  is,  we  suspect  that  deadlock  can 
occur  only  when  there  is  a  cycle  of  waiting  conditions  in  the 
graph;  this  expectation  is  born  out  in  the  next  theorem. 

Before  stating  this  theorem,  we  need  to  define  a  special 
type  of  state. 

An  expedient  state  is  a  state  in  which  no  acquisition 
operations  are  defined  (possible). 

Intuitively,  a  state  is  expedient  when  no  process  has  a 
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request  pending  which  can  be  granted-  In  most  computer 
systems,  the  state  will  usually  be  expedient;  the  only  time 
the  state  will  not  be  expedient  is  immediately  following  a 
request  but  before  the  corresponding  acquisition,  or 
immediately  following  a  release  but  before  the  released  units 
can  be  allocated-  That  is,  in  most  computer  systems,  if  a 
request  can  be  granted,  it  will  be  immediately  granted. 

In  a  reusable  resource  system,  any  state  S  can  be 
transformed  to  an  expedient  state  by  deleting  request  edges 
directed  from  processes  which  are  not  blocked;  it  should  be 
obvious  that  the  original  state  S  is  a  deadlock  state  if  and 
only  if  the  transformed  state  is  also  a  deadlock  state. 

Theorem  3.2  In  a  reusable  resource  graph, 

(1)  a  cycle  is  a  necessary  condition  for  deadlock,  and 

(2)  if  the  graph  is  expedient,  a  knot  is  a  sufficient 
condition  for  deadlock. 

Proof  First  we  prove  (1).  This  will  be  proved  by  assuming 
the  graph  does  not  contain  a  cycle  and  showing  that  the 
graph  is  completely  reducible-  If  the  graph  contains  no 
cycle  then  there  must  exist  a  linear  ordering  of  the 
nodes,  call  it  SEQ1,  with  the  property  that  if  there 
exists  a  path  in  the  graph  directed  to  node  Qi  from  node 
Qj  then  Qi  appears  before  Qj  in  the  sequence.  (See 
[pg-262,  Knuth  1968]  for  a  method  of  constructing  linear 
ordering  SEQ 1  from  the  edges  in  the  cycle  free  graph.) 
Necessarily,  the  first  node  in  this  sequence  will  be  a 
sink  and  the  last  node  will  be  a  source-  Let  us  define 
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SEQ2  to  be  a  sequence  of  process  nodes  derived  from  SEQl 
by  deleting  all  resource  nodes  and  all  process  nodes  which 
are  isolated  nodes.  We  will  now  show  that  the  graph  can 
be  completely  reduced  by  the  processes  as  they  appear  in 


SEQ2. 


Let  numbers  of  the  processes  in  SEQ2  be 


(i  1 ,12,. •  .  ,ix)  .  Let  the  original  graph  be  S,  S  can  be 
reduced  by  process  il  to  a  state,  call  it  Si,  because  any 
request  edges  directed  from  il  must  be  directed  to 
resource  nodes  which  are  sinks,  (Resources  whose  nodes 
are  sinks  have  all  their  units  available  and  no  request 
for  such  a  resource  can  cause  blocking  because  by  part  (3) 
of  the  definition  of  reusable  resource  graphs  —  see 
Section  3,3  —  no  request  can  be  for  more  than  the  total 
units  of  a  resource.)  SI  can  be  reduced  by  process  i2  to 
a  state,  call  it  S2,  because  any  request  edges  directed 
from  i2  must  be  directed  to  resource  nodes  which  are  sinks 
in  Si.  (By  the  definitions  of  SEQl  and  SEQ2,  the  only 

i 

resources  which  can  be  requested  by  i2  are  resources  whose 
nodes  are  sinks  or  whose  nodes  have  assignment  directed 
from  them  only  to  process  node  il.  Once  S  is  reduced  by 
Si,  all  such  assignment  edges  have  been  deleted,  and  these 
resource  nodes  become  sinks.)  Similarly,  S2  can  be 
reduced  by  i3  to  S3,  and  so  on,  until  a  reduction  by  ix 
results  in  state  Sx,  All  edges  in  the  original  bipartite 
graph  S  must  have  been  directed  to  or  from  non-isolated 
process  nodes,  and  thus  all  edges  in  Sx  have  been  deleted. 
Hence,  the  sequence  (i  1 , i2 , . . . , ix)  completely  reduces  S. 
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Therefore,  if  S  does  not  contain  a  cycle,  then  S  is  not  a 
deadlock  state. 

Now  we  prove  (2) .  This  will  be  proved  by  assuming 
that  the  expedient  state  contains  a  knot  and  showing  that 
every  process  in  the  knot  is  deadlocked.  No  process  in 
the  knot  can  be  a  sink;  that  is,  every  process  in  the  knot 
has  reguest  edges  directed  from  it.  Since  the  state  is 
expedient  every  process  in  the  knot  has  a  request  for  more 
units  cf  some  resource  than  are  available.  The  requested 
resources  must  also  be  in  the  knot,  and  all  processes 
which  have  been  assigned  units  of  the  requested  resource 
are  in  the  knot.  Thus,  no  process  in  the  knot  can  acquire 
its  reguested  resources  until  some  other  process  in  the 
knot  releases  some  units.  Hence,  each  process  in  the  knot 
will  always  be  blocked,  and  the  graph  is  a  deadlock  state. 

If  all  possible  requests  have  not  been  granted,  i.e.,  if 
the  state  is  not  expedient,  then  the  reusable  resource  graph 
may  contain  a  knot  and  still  not  be  a  deadlock  state.  For 
example,  in  Figure  3.4,  all  the  nodes  in  state  S  form  a  knot, 
but  state  S  is  not  deadlocked.  We  may  interpret  that  requests 
which  can  be  granted  are  ”noise"  in  the  reusable  resource 
graph,  and  that  this  noise  must  be  eliminated  before  deadlocks 
and  knots  become  equivalent. 
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Figure  3 4  Reductions  of  a  reusable  resource  graph.  S  is 
reduced  by  PI  to  ottain  T,  and  T  is  reduced  by  P2  to  obtain  U. 
S  is  completely  reducible  because  the  reductions  delete  all 
edges;  therefore  S  is  not  a  deadlock  state. 
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3.5  Two  Deadlock  Detection  Algorithms 

The  theorems  of  the  previous  section  suggest  algorithms 
for  detecting  deadlock  in  reusable  resource  graphs.  In  this 
section  we  will  give  two  such  algorithms  in  a  combination  of 
English  and  PL/I. 

Weighted  Edges 


Up  to  this  point  we  have  drawn  a  separate  edge  from  node 
Pi  to  Rj  in  the  reusable  resource  graph  for  each  unit  of  Rj 
requested  by  Pi.  Alternately,  whenever  Pi  has  requested  units 
of  Rj  we  could  draw  a  single  edge  from  node  Pi  to  node  Rj,  and 
associate  with  each  such  edge  a  strictly  positive  integer 
giving  the  number  of  units  requested.  Similarly,  when  units 
of  Rj  are  assigned  to  Pi,  we  could  draw  only  one  edge  from  Rj 
to  Pi  and  associate  with  the  edge  the  number  of  units 


assigned, 


In  Figure  3.5  we  give  an  example  of  a  reusable 


resource  graph  with  this  alternate  representation  of  requests 
and  assignments.  We  will  say  this  alternate  representation 
uses  weighted  edges.  This  representation  does  not  provide  as 
clear  a  picture  of  the  system  state  as  is  given  using  multiple 
edges  and  subnodes  representing  units  of  the  resource; 
however,  it  offers  the  advantage  of  limiting  the  number  of 


edges  in  the  graph  to  2  ra  n,  regardless  of  the  number  of  units 
in  each  resource.  The  algorithms  for  detecting  deadlock  will 
assume  that  weighted  edges  are  used  in  the  graphs. 
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Detection  with  Execution  Time  Proportional  to  m  n2 

Each  of  the  two  deadlock  detection  algorithms  finds  a 
process  which  is  not  blocked  and  which  is  not  an  isolated 
node,  and  reduces  the  state  by  that  process.  Then  the 
algorithm  finds  another  such  process  and  reduces  it,  and  so 
on.  From  Lemma  3.  1  it  follows  that  the  order  of  the 
reductions  is  immaterial.  If  the  reductions  leave  all 
processes  not  blocked  then  the  state  was  not  deadlocked. 

4 

The  difficulty  in  this  technique  of  detecting  deadlock  is 
that  once  a  reduction  takes  place,  it  is  not  immediately 
obvious  which  new  reductions  become  possible,  i.e.,  which 
processes  become  not  blocked. 

One  way  to  handle  this  difficulty  is  to  rescan  the  list 
of  processes  nodes  each  time  a  reduction  is  made,  searching 
for  another  process  to  reduce.  The  rescanning  is  continued 
until  a  complete  scan  of  the  list  of  process  nodes  finds  that 
no  more  reductions  can  be  made;  the  system  is  not  deadlocked 
if  the  final  scan  leaves  all  edges  deleted.  This  is  the 
approach  taken  in  Algorithm  3.1.  This  algorithm  does  a  linear 
scan  of  the  list  of  nodes  until  finding  a  process  node  to 
reduce  (in  statement  10) ;  at  that  point  the  node  is  reduced 
and  the  scan  is  set  again  to  the  beginning  of  the  list  (in 
statement  16) . 

This  repeated  scanning  of  the  list  of  process  nodes  will 
require  n+  (n  —  1)  ♦  (n— 2)  ...  +1  =  n(n  +  1)/2  inspections  of 
process  nodes  (in  Do— group  4)  in  the  case  where  the  processes 
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on  the  list  are  in  order  (Pi#  P2,  .  ..,  Pn) ,  but  the  only 
possible  order  of  reductions  is  (Pn,  ...,  P2,  PI).  Inspecting 
a  process  to  see  if  it  can  be  reduced  requires  inspecting  all 
edges  directed  from  the  process  node  (this  is  potentially  m 
edges,  one  for  each  resource).  Thus,  the  execution  of 
Algorithm  3. 1  for  the  worst  graphs  takes  time  proportional  to 
m  n2. 

Algorithm  3.1  is  similar  to  Haberraann*s  algorithm  [1969] 
which  is  used  to  prevent  deadlock  (in  Section  3.9  we  show  the 
relationship  between  algorithms  which  detect  deadlock  and 
those  used  to  prevent  deadlock).  Algorithm  3.1  is  also 
similar  to  the  one  given  by  Shoshani  [1969a]  to  detect 
deadlock.  The  main  difference  between  this  algorithm  and  the 
algorithms  of  Habermann  and  Shoshani  is  that  theirs  are  matrix 
manipulation  routines,  while  this  algorithm  is  a  graph  (or 
list)  manipulation  routine. 

Detection  with  Execution  Time  Proportional  to  m  n 

The  algorithm  can  be  made  faster  if  the  rescanning  of  the 
process  nodes  can  be  avoided.  This  is  accomplished  in 
Algorithm  3.2  by  two  devices:  the  reguests  for  each  resource 
are  ordered  by  size,  and  each  process  node  has  a  wait  count 
which  gives  the  number  of  request  edges  which  cause  the 
process  to  be  blocked.  For  example,  in  Figure  3.5,  the  wait 
count  for  process  P 1  is  0  because  PI  can  be  granted  all  its 
requests,  and  the  wait  count  for  process  P2  is  1  because  P2 
can  not  be  granted  its  request  for  resource  HI.  (Even  though 
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a  process  may  request  many  units  of  a  given  resource,  the 
request  for  that  resource  contributes  only  one  to  the 
process's  wait  count.) 

Before  Algorithm  3.2  is  executed,  the  wait  count  for  each 
process  must  be  initialized.  Those  processes  whose  wait 
counts  are  zero,  but  which  have  no  allocations  are  considered 
already  reduced.  The  “list  to  be  reduced”  is  initialized  to 
contain  those  processes  with  a  zero  wait  count  and  with  some 
allocations.  The  requests  for  each  resource  must  be  ordered 
by  size.  When  a  process  Pi  which  has  been  allocated  units  of 
resource  Rj  is  reduced  (in  Do-group  2) ,  the  available  units  of 
Rj  are  increased  by  the  units  allocated  to  Pi,  and  all 
processes  which  can  now  be  granted  their  request  for  Rj  have 
their  wait  counts  decremented  by  one.  Since  the  list  of 
processes  requesting  Rj  is  ordered  by  request  size,  there  is 
no  searching  to  find  processes  whose  requests  can  be  granted. 
Once  a  process's  wait  count  reaches  zero,  the  process  is  no 

i 

longer  blocked,  and  so  it  is  added  to  the  list  of  processes  to 
be  reduced  (in  statement  7) . 

The  maximum  execution  time  of  Algorithm  3.2  is  K1  Er  +  K2 
Ea  ♦  K3  n  ♦  K4  where  Kl,  K2,  K3,  and  K4  are  constants,  Er  is 
the  number  of  request  edges,  Ea  is  the  number  of  allocation 
edges,  and  n  is  the  number  of  processes.  Since  Er  and  Ea  are 
limited  by  the  product  of  the  number  of  processes  and  the 
number  of  resources,  the  maximum  execution  time  of  Algorithm 
3.2  is  proportional  to  m  n. 

While  Algorithm  3.2  was  developed  by  the  author,  a 
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similar  algorithm  which  uses  matrix  manipulation  has  been 
developed  independently  by  Russell  [  1970  ]. 

Ordering  the  Requests 

Algorithm  3.1  has  the  advantage  that  it  requires  little 
initialization  before  analyzing  the  system  state.  By 
comparison,  before  Algorithm  3.2  can  be  executed,  the  wait 
counts  for  each  process  must  be  set  and  the  requests  for  each 
resource  must  be  sorted.  There  is  a  significant  advantage  to 
maintaining  the  wait  counts  and  the  sorted  requests  during 
system  operation.  This  advantage  is  that  following  a  release, 
no  searching  is  necessary  to  find  processes  which  have  become 
able  to  acquire  their  requested  units;  these  processes  will  be 
exactly  the  ones  whose  wait  counts  became  zero  as  a  result  of 
the  release.  If  the  wait  counts  and  sorted  requests  are 
maintained.  Algorithm  3.2  will  be  considerably  faster  than 
Algorithm  3.1. 

If  it  is  not  convenient  to  maintain  the  requests  in 
increasing  order  then  the  requests  for  each  resource,  call  it 
Si,  can  be  sorted  by  the  following  code: 

1.  Do  for  each  process  Pi  requesting  units  of  Ri; 

2.  Add  Pi  to  list  number  L  where  L  is  the 

number  of  units  of  Ri  requested  by  P; 

3.  End; 

4.  Do  for  L  =  1  to  ti; 

5.  Do  for  each  process  P  on  list  L; 

6.  Add  P  to  sorted  list  of  processes 

requesting  R; 

7.  End; 

8.  End; 

This  code  uses  a  separate  list  for  every  possible  size  of 
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request.  For  a  given  resource,  a  single  pass  through  the 
requests  adds  each  requesting  process  to  the  appropriate  list. 
Next,  a  single  pass  through  these  lists  produces  a  sorted  list 
of  requests  for  the  resource.  Since  the  code  is  executed  once 
for  every  resource.  Do-group  1  is  executed  Er  times  (once  for 
each  requesting  edge).  Do-group  4  is  executed  1 1+t2+. . . +  tm 
times  (once  for  every  unit  in  the  system) ,  and  Do-group  5  is 
executed  Er  times  (cnce  for  each  execution  of  Do-group  1). 
Thus  the  time  for  sorting  all  the  requests  is  K1  Er  +  K2  (tl  + 

j 

t2  +  ...  «■  tm)  .  If  tl  ♦  t2  ♦  ...  ♦  tm  is  not  too  large  then 

this  code  provides  a  fast  method  of  sorting  the  requests 
before  applying  Algorithm  3.2. 

Continuous  Deadlock  Detection 

In  some  computing  systems  it  may  be  advantageous  to 
maintain  a  continuous  knowledge  of  whether  the  system  state  is 
deadlocked.  Presumably,  the  state  will  not  usually  be 

i 

deadlocked,  and  as  soon  as  the  state  becomes  deadlocked,  some 
action  will  be  taken  to  remove  the  deadlock. 

Continuous  deadlock  detection  should  be  implemented  by 
testing  for  deadlock  after  each  operation  which  can  change  a 
state  which  is  not  deadlocked  to  a  state  which  is  deadlocked. 
Informally,  if  an  operation  changes  the  state  from  being  not 
deadlocked  to  being  deadlocked,  we  say  the  operation  "causes” 
deadlock.  The  following  lemma  tells  which  operations  can 

cause  deadlock. 

Lemma  3.3  In  a  reusable  resource  system,  suppose  S  is  not 
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a  deadlock  state,  and  an  operation  by  process  Pi  changes 
state  S  to  state  T.  Then  T  is  a  deadlock  state  if  and 
only  if  the  operation  is  a  request  and  Pi  is  deadlocked  in 

T. 

Proof  The  lemma  will  be  proved  by  showing  (a)  that 
acquisition  and  release  operations  can  not  cause  deadlock 
and  (b)  that  a  request  can  cause  deadlock  only  when  the 
requesting  process  becomes  deadlocked. 

First  we  show  that  if  the  operation  is  an  acquisition 
then  T  can  not  be  deadlocked.  This  is  true  because  Pi  is 
blocked  in  neither  S  nor  T,  and  reducing  S  and  T  by  Pi 
yields  the  same  state.  Thus,  since  S  is  not  deadlocked, 
then  neither  is  T  deadlocked.  A  similar  argument  shows 
that  if  the  operation  is  a  release,  then  T  is  not 
deadlocked. 

Now  we  show  that  if  the  operation  is  a  request  then  T 
is  deadlocked  if  and  only  if  Pi  is  deadlocked  in  T.  If  Pi 
is  deadlocked  in  T  then  by  definition,  T  is  deadlocked. 
If  Pi  is  not  deadlocked  in  T  then  state  T  can  be  reduced 
to  state  U  in  which  Pi  is  not  blocked.  The  available 
units  in  U  must  be  at  least  as  large  as  the  available 
units  of  S,  and  therefore  the  same  sequence  of  reductions 
which  completely  reduces  S  can  completely  reduce  0  (we 
delete  from  the  sequence  those  processes  whose  reductions 
changed  T  to  U) .  Hence,  if  Pi  is  not  deadlocked  in  T, 
then  T  is  completely  reducible  and  is  not  a  deadlock 


state. 
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Lemma  3.3  tells  us  that  only  a  request  which  can  not  be 
granted  can  cause  a  deadlock,  and  this  deadlock  must  involve 
the  requesting  process.  After  a  request  which  can  not  be 
granted  we  can  shorten  the  execution  of  Algorithms  3.1  and  3.2 
by  adding  a  test  to  see  if  a  process  which  can  be  reduced  is 
the  requesting  process.  In  Algorithm  3.1  the  requesting 
process  should  be  put  at  the  beginning  of  the  list  of 
processes  so  that  each  new  scan  tries  to  reduce  that  process 
first,  and  following  statement  1 1  should  be  inserted  the  two 
statements: 

If  P  is  the  requesting  process  then 
Return  indicating  no  deadlock. 

In  Algorithm  3.2,  statement  7  should  be  replaced  by 

Do ; 

If  Q  is  the  requesting  process  then 

Return  indicating  no  deadlock; 

Add  Q  to  the  list  to  be  reduced; 

End ; 

In  both  algorithms  the  final  statement  can  be  replaced  by  an 
indication  that  the  system  state  is  deadlocked,  because 
process  P  could  not  be  reduced.  Although  these  changes  do  not 
decrease  the  maximum  running  time  of  the  algorithms,  they  help 
considerably  in  the  typical  case  in  which  the  process  in 
question  is  no  longer  blocked  after  a  few  reductions. 
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PI 


3.^5  Using  weighted  edges  to  represent  the  system  state 
given  in  Figure  3.2.  The  number  in  each  resource  node  gives 
the  available  units  of  the  resource. 
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4. 

5. 
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8. 
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10. 

11. 

12. 

13. 

14. 

15. 

16. 

17. 

18. 

19. 

20. 


Point  to  beginning  of  list  of  process  nodes; 

Do  for  next  process  node  P  on  list  of  process  nodes; 
If  process  node  P  has  not  been  reduced  then 
Do;  /*See  if  P  can  be  reduced.*/ 

Canreduce  =  true; 

Do  for  each  edge  E  directed  from  P; 

If  reguest  given  by  E  cannot  be  granted  then 
Canreduce  =  false; 

End ; 

If  Canreduce  then 
Do;  /*Reduce  by  P.*/ 

Do  for  each  edge  E  directed  to  P; 

Delete  edge  E; 

End; 

Hark  P  as  reduced; 

Point  to  beginning  of  list  of  process  nodes; 
End; 

End; 

End ; 

Deadlock  =  (Not  all  process  nodes  are  now  reduced)  ; 


Algorithm _ 3^2  Deadlock  detection  in  a  reusable  resource 


system.  Maximum  execution  time  is  proportional  to  m  n2. 


1-  Do  for  each  process  node  P  on  list  to  be  reduced; 

2.  Do  for  each  resource  R  allocated  to  P; 

3.  Increase  available  units  of  R  by  units 

allocated  to  P; 

4.  Do  for  each  process  Q  whose  request  for  R 

can  now  be  granted; 

5.  Decrease  wait  count  of  Q  by  1; 

6.  If  the  wait  count  of  Q  is  zero  then 

7.  Add  Q  to  list  to  be  reduced; 

8.  End; 

9.  End; 

10.  End; 

11.  Deadlock  =  (Not  all  process  nodes  are  now  reduced); 


Algorithm _ 3^2  Deadlock  detection  in  a  reusable  resource 

system.  Maximum  execution  time  is  Kl  Er  ♦  K2  Ea  +  K3  n  ♦  K4, 
and  thus  is  proportional  to  m  n. 
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3.6  Special  Cases  of  Reusable  Resource  Systems 

While  Algorithms  3.1  and  3.2  handle  the  most  general  case 
of  a  reusable  resource  graph,  important  simplifications  in  the 
algorithms  can  be  made  for  special  cases.  We  will  consider 
the  simplif ications  which  arise  when  the  system  has  the 
following  charac teristics. 

Single  unit  resources.  Each  resource  in  the  system 
contains  only  one  unit,  that  is,  tl  -  t2  =  ...  =  tm  =  1. 
Records  of  an  update-in-place  file  are  typical  of  this 
type  of  resource,  and  the  OS/360  Eng  -  Deq  macros  [IBM 
1968a]  are  examples  of  mechanisms  which  allow  sharing  of 
single  unit  resources. 

Si nqle  unit  requests.  A  process  may  request  only  one  unit 
at  a  time.  In  a  reusable  resource  graph  this  means  that 
at  most  one  request  edge  is  directed  from  each  process 
node,  and  all  request  edges  are  for  one  unit.  A 
disadvantage  to  single  unit  requests  is  that  even  though  a 
process  requires  several  units  to  continue,  it  must 
acquire  them  one  by  one,  and  therefore  the  first  acquired 
units  remain  idle  until  the  last  are  acquired.  This  may 
also  result  in  a  higher  frequency  of  deadlocks  because  a 
process  requiring  many  units,  say  U  units,  will  need  to 
make  requests  while  it  holds  1,  2,  ...,  0-2  and  u- 1  units. 
Single  t_yqe  of  resource.  There  is  only  one  resource  in 
the  system,  although  this  resource  may  contain  many  units; 
that  is,  in  —  1 ,  Processes  sharing  only  a  pool  of  buffers 
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are  an  example  of  a  system  with  a  single  type  of  resource. 
It  is  obvious  from  the  execution  time  of  Algorithm  3.2,  K1  Er 
+  K2  Ea  +  K 3  n  +  K4,  that  each  of  these  characteristics  will 
save  some  execution  time.  In  a  system  with  single  unit 
resources,  the  maximum  number  of  units  which  can  be  allocated 
is  the  number  of  resources,  m;  thus  the  number  of  assignment 
edges  Ea  is  limited  to  m.  In  a  system  with  single  unit 
reguests,  the  number  of  request  edges  Er  is  limited  to  the 
number  of  processes,  n.  In  a  system  with  a  single  type  of 
resource  the  number  of  request  edges  Er  and  the  number  of 
allocation  edges  Ea  are  each  limited  to  the  number  of 
processes,  n. 


It  is  probably  not  within  the  power  of  the  systems 
designer  to  dictate  that  a  system  will  use  only  single  unit 
resources  or  only  a  single  type  of  resource,  and  we  do  not 
suggest  that  he  save  execution  time  by  attempting  to  enforce 
such  simplifications.  The  suggestion  is  that  if  the  system 

i 

naturally  has  single  unit  resources  or  a  single  type  resource 
then  the  designer  should  take  advantage  of  the  special  case 
algorithms  which  we  describe  below.  It  may  very  well  be 
within  the  power  of  the  system  designer  to  dictate  that 
requests  will  be  by  single  units.  Even  if  the  processes  are 
allowed  to  request  many  units  at  once,  the  designer  can 
convert  these  requests  to  single  unit  requests  within  the 
operations  which  implement  resource  allocation.  The  simpler 
deadlock  detection  algorithms  which  result  could  influence  the 
designer  to  enforce  single  unit  requests. 
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Single  Unit  Eesoucces 

We  first  consider  the  simplification  afforded  by  single 
unit  resources.  In  Section  3.4  it  was  proved  that  a  cycle  is 
a  necessary  condition  for  deadlock  in  a  reusable  resource 
graph.  We  now  show  that  if  there  are  only  single  unit 
resources  then  a  cycle  is  also  a  sufficient  condition  for 
deadlock. 

Theorem _ _3.3  A  reusable  resource  graph  with  single  unit 

resources  is  a  deadlock  state  if  and  only  if  it  contains  a 
cycle. 

Proof  Since  Theorem  3. 2{1)  states  that  a  cycle  is  a 
necessary  condition  for  deadlock,  we  have  only  to  prove 
that  a  cycle  is  a  sufficient  condition  for  deadlock  when 
the  graph  has  only  single  unit  resources.  This  proof  will 
be  similar  to  the  proof  of  part  (2)  of  Theorem  3.2.  We 
will  assume  the  graph  contains  a  cycle,  and  will  show  that 
every  process  in  the  cycle  is  deadlocked.  No  process  in 
the  cycle  is  a  sink;  that  is,  every  process  in  the  cycle 
has  request  edges  directed  from  it.  Each  resource  node  in 
the  cycle  has  exactly  one  assignment  edge  directed  from  it 
because  (a)  the  node  can  not  be  a  sink  and  (b)  there  is 
only  one  unit  of  the  resource.  Thus,  the  single  unit  of 
every  resource  in  the  cycle  has  been  assigned  to  a  process 
in  the  cycle,  and  every  process  in  the  cycle  has  a  request 
for  the  single  unit  of  some  resource  in  the  cycle.  As  a 
result,  nc  process  in  the  cycle  can  acquire  its  requested 
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units  until  some  other  process  in  the  cycle  releases 
units.  Hence,  each  process  in  the  cycle  will  always  be 
blocked,  and  the  graph  is  a  deadlock  state. 

Detecting  Deadlock  by  Detecting  Cycles 

For  reusable  resource  graphs  with  single  unit  resources, 
we  can  detect  deadlock  by  testing  the  graph  for  cycles. 
Algorithm  3.3,  which  is  similar  to  algorithms  given  by 
Marimont  [1959]  and  Knuth  [1966],  determines  if  a  directed 
graph  contains  a  cycle.  The  algorithm  works  by  successively 
deleting  edges  directed  to  sinks;  if  all  nodes  become  sinks 
then  there  was  no  cycle.  Before  the  algorithm  is  executed,  a 
list  must  be  initialized  to  contain  all  sinks  and  a  wait  count 
for  each  node  is  set  to  the  number  of  edges  directed  from  the 
node.  Algorithm  3.3  is  fast,  executing  Do-group  1  at  most  N 
times,  where  N  is  the  total  number  of  nodes  in  the  graph,  and 
Do-group  2  at  most  E  times,  where  E  is  the  total  number  of 

t 

edges  in  the  graph.  If  at  most  one  edge  is  directed  from  a 
given  node  to  another  node  in  the  graph  and  the  graph  is 
bipartite,  then  E  is  limited  to  2  m  n  and  maximum  execution 
time  is  proportional  to  m  n. 

Algorithm  3.3  is  smaller  and  faster  than  the  detection 
algorithms  for  the  general  case  (Algorithms  3.1  and  3.2),  and 
it  does  not  reguire  that  the  reguests  be  sorted  (all  requests 
are  the  same  size). 

If  the  system  is  known  to  be  in  a  state  which  is  not 
deadlocked  then  by  Lemma  3.3,  only  a  request  which  can  not  be 
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granted  can  result  in  a  deadlock,  and  such  a  deadlock  can  be 
detected  by  testing  to  see  if  the  requesting  process  is 
deadlocked.  It  is  easily  shown  that  the  requesting  process 
will  be  deadlocked  only  if  it  is  in  a  cycle.  Therefore,  if 
the  state  is  not  deadlocked  and  process  Pi  makes  a  request 
which  can  not  be  granted,  then  the  new  state  will  be 
deadlocked  only  if  node  Pi  is  in  a  cycle. 

Algorithm  3.4  gives  a  method  of  determining  if  a  node  is 
in  a  cycle.  The  algorithm  works  by  tracing  all  paths  starting 
with  the  node  to  see  if  the  node  reappears. 

Algorithm  3.4  is  fast,  executing  in  maximum  time  Kl  E  ♦ 
K2  N  *  K3,  as  we  can  see  from  the  observations  that 

Do-group  3  is  executed  at  most  N  times,  once  for  each  node 
<N  =  m  ♦  n) . 

Do-group  4  is  executed  at  most  E  times,  once  for  each 
edge. 

In  a  reusable  resource  graph  with  single  unit  resources,  E  is 
.limited  by  2  m  n  and  thus,  maximum  execution  time  is 
proportional  to  ra  n.  In  the  usual  case  in  which  the  state  is 
not  deadlocked.  Algorithm  3.3  will  add  all  nodes  in  the  graph 
to  its  list,  while  Algorithm  3.4  will  add  to  its  list  only  the 
progeny  of  node  P.  Thus  for  the  usual  case.  Algorithm  3.4 
will  be  considerably  faster  than  Algorithm  3.3. 

Algorithms  3.3  and  3.4  can  be  made  slightly  faster  (and 
slightly  larger)  by  taking  advantage  of  the  fact  that  the 
graph  is  bipartite  and  that  the  resource  nodes  have  at  most 
one  son.  Using  the  fact  that  the  graph  is  bipartite,  the 
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algorithms  can  handle  two  generations  in  each  iteration;  the 
comparison  in  statement  5  of  Algorithm  3.4  is  thereby  avoided 
when  P  would  be  compared  with  a  resource  node.  Algorithm  3.4, 
as  modified  to  handle  two  generations  at  once,  is  essentially 
the  algorithm  given  by  Collier  [1968]  to  detect  deadlock  on  a 
continuous  basis  in  systems  with  only  single  unit  resources. 

Single  Unit  Bequests 


Now  let  us  suppose  that  the  system  has  single  unit 
requests,  though  not  necessarily  single  unit  resources.  In 
Section  3.4  it  was  proved  that  a  knot  is  a  sufficient 
condition  for  deadlock  in  an  expedient  reusable  resource 
graph.  We  now  show  that  if  there  are  only  single  unit 
requests  then  a  knot  in  an  expedient  state  is  a  necessary 
condition  for  deadlock. 

Theorem _ 3. 4  An  expedient  reusable  resource  graph  with 

single  unit  requests  is  a  deadlock  state  if  and  only  if  it 

i 

contains  a  knot. 

Proof  Theorem  3.2(2)  states  that  a  knot  is  a  sufficient 
condition  for  deadlock  in  an  expedient  state.  Thus  we 
need  to  prove  that  a  knot  is  a  necessary  condition  for 
deadlock  when  the  expedient  state  has  only  single  unit 
requests.  We  will  assume  the  reusable  resource  graph  S 
does  not  contain  a  knot  and  will  show  that  for  any  process 
a  sequence  of  reductions  can  be  found  that  leaves  that 
process  not  blocked.  If  there  is  no  knot  then  for  an 
arbitrary  process  node  numbered  i,  either  the  process  node 
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is  a  sink  or  there  is  a  path  directed  from  the  process 
node  to  a  sink-  (See  Lemma  3.1.)  Let  the  numbers  of  the 
process  nodes  on  such  a  path  be,  in  order,  i,  jl,  j2,  .  .., 
jx.  Since  the  state  is  expedient,  the  sink  at  the  end  of 
the  path  must  be  a  process  node  (the  node  for  process  jx) ; 
otherwise  the  state  would  not  be  expedient  because  process 
jx  would  be  requesting  a  unit  of  a  resource  (whose  node 
would  be  the  sink)  which  would  be  available.  We  now  show 
that  S  can  be  reduced  by  processes  jx,  ...,  j2,  and  jl,  in 
that  order,  leaving  a  state  in  which  process  i  is  not 
deadlocked.  Since  process  jx  is  not  blocked  (it  has  no 
request  edge  directed  from  it)  and  since  jx  is  not  an 
isolated  node,  S  can  be  reduced  by  jx.  Once  S  is  reduced 
by  jx,  the  previous  process  on  the  path  (j  x-1)  is  no 
longer  blocked,  because  it  has  a  request  for  only  one  unit 
of  one  resource,  and  at  least  one  unit  of  that  resource 
became  available  when  S  was  reduced  by  process  jx.  Hence, 
S  can  be  reduced  by  the  last  process  (jx)  on  the  path  and 
taen  by  the  next  to  last  process  (j  x-1)  on  the  path. 
Proceeding  inductively,  S  can  be  reduced  in  order  by  jx, 
...,  j2,  jl,  thereby  leaving  process  i  not  blocked.  Thus, 
an  arbitrary  process  numbered  i  is  not  deadlocked  in  S- 
Hence,  an  expedient  reusable  resource  graph  with  single 
unit  requests  can  not  be  a  deadlock  state  unless  it 


contains  a  knot. 
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Detecting  Deadlock  by  Detecting  Knots 

For  expedient  reusable  resource  graphs  with  single  unit 
reguests,  we  can  detect  deadlock  by  testing  the  graph  for  a 
knot.  Knots  play  the  same  role  in  these  graphs  that  cycles 
play  in  reusable  resource  graphs  with  single  unit  resources, 
i.e.  ,  they  are  a  necessary  and  sufficient  condition  for 
deadlock.  Methods  of  detecting  knots  are  quite  similar  to 
methods  of  detecting  cycles,  and  this  discussion  of  knot 
detection  will  parallel  our  previous  discussion  of  cycle 
detection. 

Algorithm  3.5  determines  whether  a  directed  graph 
contains  a  knot.  The  algorithm  works  by  successively  making 
every  father  of  a  sink  into  a  sink;  if  all  nodes  become  sinks 
then  there  was  no  knot.  Like  Algorithm  3.3,  the  maximum 
execution  time  of  Algorithm  3.5  is  proportional  to  m  n  when 
the  graph  is  bipartite  and  at  most  one  edge  is  directed  from  a 

i 

given  node  to  another  given  node. 

Algorithm  3.5  is  slightly  faster  than  Algorithm  3.3 
because  its  inner  Do-group  contains  one  less  statement,  and  it 
is  smaller  because  it  does  not  require  a  wait  count  for  each 
node. 

Algorithm  3.5  offers  a  particularly  economical  way  to 
test  for  deadlock;  it  requires  neither  wait  counts  nor  sorted 
requests  and  its  inner  Do-group  contains  only  two  statements. 
It  is  surprising  that  a  change  as  innocent  appearing  as 
limiting  requests  to  a  single  unit  can  cause  such  significant 
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savings  in  time  and  space. 

If  the  system  is  known  to  be  in  a  state  which  is  not 
deadlocked  then  by  Lemma  3.3,  only  a  request  which  can  not  be 
granted  can  result  in  a  deadlock,  and  such  a  deadlock  can  be 
detected  by  testing  to  see  if  the  requesting  process  is 
deadlocked.  It  is  easily  shown  that  the  requesting  process 
will  be  deadlocked  only  if  it  is  in  a  knot.  Therefore,  if  the 
state  is  not  deadlocked  and  process  Pi  makes  a  request  which 
can  not  be  granted,  then  the  new  state  will  be  deadlocked  only 
if  node  Pi  is  in  a  knot. 

Algorithm  3.6  gives  a  method  of  determining  if  the 
requesting  process  Pi  is  in  a  knot.  The  algorithm  works  by 
following  all  paths  from  node  Pi;  if  a  path  leads  to  a  sink 
then  Pi  is  not  in  a  knot  and  is  not  deadlocked.  Like 
Algorithm  3.4,  the  maximum  execution  time  of  Algorithm  3.6  is 
K 1  E  +  K2  N  ♦  K3  where  N  is  the  total  number  of  nodes  in  the 
graph  and  E  is  the  number  of  edges  in  the  graph.  For  an 
expedient  reusable  resource  graph  with  single  unit  requests, 
the  maximum  execution  time  of  Algorithm  3.6  is  proportional  to 

ID  II  m 

When  a  continuous  knowledge  of  whether  the  system  is 
deadlocked  is  required.  Algorithms  3.4  and  3.6  offer  fast 
execution  time,  because  only  the  progeny  of  the  process  node 
in  question  are  inspected  by  the  algorithms.  This  advantage 
is  due  to  the  fact  that  these  algorithms  are  top  down,  tracing 
from  son  to  son  to  son.  In  the  general  case  of  multiple  unit 
requests  and  resources,  no  fast  top  down  algorithm  is  known. 


SECTION  3.6 


80 


and  such  an  algorithm  is  "unlikely”  because  of  the  complicated 
combinatoric  implications  of  the  resource  nodes.  For  example, 
three  units  of  a  resource  will  become  available  when  any  three 
processes  each  release  one  unit,  or  when  any  one  process 
releases  one  unit  and  any  other  process  releases  two,  or  when 
any  one  process  releases  three  units.  An  algorithm  for  the 
general  case  could  be  made  top  down  and  then  bottom  up  by 
first  marking  all  progeny  of  the  node  in  question  (by  tracing 
son  to  son  to  son)  and  then  only  using  these  marked  nodes  in 
Algorithm  3.2  (which  traces  father  to  father  to  father).  This 
technique  would  prevent  Algorithm  3.2  from  wasting  time 
reducing  processes  which  are  not  waited  for,  even  indirectly, 
by  the  process  in  question. 

Single  Unit  Resources  and  Single  Unit  Requests 

If  the  system  has  both  single  unit  resources  and  single 
unit  requests  then  deadlock  detection  becomes  simpler  again. 

i 

In  this  case,  knots,  deadlocks,  and  cycles  become  equivalent, 
and  the  reusable  resource  graph  has  the  property  that  each 
node  can  have  at  most  one  son.  Taking  advantage  of  this 
property  we  can  detect  cycles  using  Algorithm  3.3  with 
statements  3  and  4  deleted;  no  wait  count  is  required  in  the 
modified  algorithm  because  the  maximum  wait  count  (number  of 
sons)  is  1.  Since  the  number  of  edges  in  a  reusable  resource 
graph  with  single  unit  requests  and  single  unit  resources  is 
at  most  ro  assignment  edges  plus  n  request  edges,  the  maximum 
execution  time  of  the  modified  algorithm  is  proportional  to 
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m  +  n. 


If 

the  state 

is 

not 

deadlocked  and 

process 

Pi  makes  a 

request 

which  can 

not 

be 

granted,  then 

Algorithm  3- 7  will 

detect 

deadlock. 

This 

algorithm,  which 

is  a 

simplified 

version  of  Algorithm  3.4,  takes  advantage  of  the  fact  that  the 
graph  is  bipartite  and  uses  ”the  son  of  the  son  of”  the  node. 
Algorithm  3.7  will  work  correctly  if  we  make  it  slightly 
smaller  (and  slightly  slower)  by  changing  ”the  son  of  the  son 
of”  to  ”the  son  of”  in  statements  1  and  3.  Since  the  graph  is 
bipartite,  a  cycle  can  contain  at  most  2  min(m,n)  nodes 
(before  repeating  a  node)  and  thus  Do-group  2  in  Algorithm  3.7 
is  executed  at  most  min{m,n)  times.  As  a  result.  Algorithm 
3.7  has  the  desirable  and  somewhat  suprising  characteristic 
that  when  the  number  of  processes  n  is  larger  than  the  number 
of  resources  m  then  the  maximum  execution  time  is  independent 
of  n.  Conversely,  if  m  is  larger  than  n  then  the  maximum 
execution  time  is  independent  of  m.  This  means  that  when  m  or 
n  is  small,  the  algorithm  is  fast. 

A  Single  Type  cf  Resource 

Finally,  let  us  consider  the  simplifications  introduced 
when  the  system  has  a  single  type  of  resource.  The  obvious 
simplifications  of  Algorithms  3.1  and  3.2  for  this  case  are 
given  by  Algorithms  3.8  and  3.9.  The  maximum  execution  times 
for  these  new  algorithms  are  proportional  to  n2  and  n, 
respectively.  Algorithm  3.8  is  essentially  the  same  as  the 
algorithm  originally  given  by  Dijkstra  [1965a]  for  preventing 
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deadlock.  (See  Section  3.9  for  a  discussion  of  how  deadlock 
detection  algorithms  can  be  used  to  prevent  deadlock.) 
Algorithm  3.  8  is  very  similar  to  an  algorithm  which  sorts  a 
list  by  first  sequentially  scanning  for  the  smallest  item, 
next  sequentially  scanning  for  the  next  to  smallest  item,  and 
so  on.  This  repeated  scanning  is  the  reason  the  maximum 
execution  time  is  proportional  to  n2.  Algorithm  3.9  assumes 
the  requests  for  the  resource  are  initially  in  order  by 
increasing  size  of  request;  thus  we  can  interpret  that 
Algorithm  3.9  gains  speed  over  Algorithm  3.8  by  assuming  away 
a  large  portion  of  the  work  (sorting)  done  by  3.8.  During  the 
operation  of  the  system,  it  may  be  convenient  to  maintain  the 
requests  in  order  by  size  so  that  processes  whose  reguests  can 
be  granted  can  be  found  quickly;  if  this  is  the  case  then 
Algorithm  3. 9  is  certainly  the  better  algorithm  of  the  two  to 
use. 


We  will  use  the  following  definitions  in  giving  a  third 
method  of  deadlock  detection  for  a  single  type  of  resource. 
(Since  there  is  only  one  type  of  resource,  we  use  the  scalar  t 
to  give  the  total  number  of  units.) 

HO  =  number  of  units  not  allocated  or  allocated  to 

processes  having  no  requests. 

Hg  =  number  of  units  allocated  to  processes  having  a 

request  for  j  units  (1  <  j  <  t) . 

Theorem _ 3_.5  In  a  resource  allocation  system  with  a  single 

ty  pe  of  resource, 

(a)  process  Pi  with  a  request  for  0  units  is  not 
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deadlocked  if  and  only  if 

HO  ♦  HI  ♦  ...  +  flj  >  j  +  1  for  0  <  j  <  0; 

(b)  the  system  state  is  not  deadlocked  if  and  only  if 
HO  *  HI  ♦  ...  «■  Hj  >  j  +  1  for  0  <  j  <  t; 

(c)  if  there  are  only  single  unit  requests  then  the  system 
state  is  not  deadlocked  if  and  only  if  HO  >  1. 

Proof  The  proof  of  (a)  follows  from  the  fact  that  if  the 
processes  can  be  reduced,  they  can  be  reduced  in  order  of 
their  sizes  of  request.  Processes  with  no  request  (and 
with  allocated  units)  can  always  be  reduced,  so  there  are 
HO  units  available  to  reduce  the  first  process  with  a 
request  for  one  unit.  Thus  a  process  with  a  request  for 
one  unit  can  become  not  blocked  if  and  only  if  HO  >  1; 
therefore  (a)  is  true  for  0=1.  If  HO  >  1,  and  HO  +  HI  > 
2  then  all  processes  with  requests  for  one  or  no  units  can 
be  reduced,  and  after  their  reductions,  there  are  two 
units  available  to  grant  any  request  for  U  =  2  units. 
Thus  a  process  with  a  request  for  0=2  units  is  not 
deadlocked.  If  HO  >  1  or  HO  +  Hi  >  2  is  not  true  then  any 
request  for  0  =  2  units  can  never  be  granted,  and  thus  a 
process  with  such  a  request  is  deadlocked.  Therefore  (a) 
is  true  for  0=2.  Continuing  by  induction,  (a)  is  true 
for  any  value  of  U,  1  <  U  <  t.  He  have  now  proved  part 
(a)  .  Part  (b)  follows  from  applying  (a)  to  all  processes. 
Part  (c)  follows  from  limiting  0  to  one  and  applying  (a) 
to  all  processes. 

Algorithm  3.10  uses  Theorem  3.5(b)  to  detect  deadlock. 
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{Notice  that  the  comparison  of  Sum  to  j  in  statement  2  is  made 
after  j  is  set  to  its  value  for  the  next  execution  of  the 
Do-group.)  This  algorithm  reguires  the  storing  and 
initialization  of  the  H  vector,  but  it  does  not  require  that 
the  requesting  processes  be  ordered  by  request  size.  The  H 
vector  can  easily  be  maintained  during  the  running  of  the 
system,  or  it  can  be  initialized  by  a  single  scan  of  the 
unordered  requests.  To  see  if  a  particular  process  having  a 
request  for  U  units  is  deadlocked,  the  algorithm  is  modified 
by  replacing  each  occurrence  of  t  with  U. 

If  the  system  has  single  unit  requests,  as  well  as  a 
single  type  of  resource,  then  part  (c)  of  Theorem  3.5  allows 
us  to  test  for  deadlock  by  seeing  if  HO  is  equal  to  zero. 
There  could  scarcely  be  a  simpler  deadlock  detection  algorithm 
than  this! 

In  systems  with  a  single  type  of  resource  there  is  a 
choice  of  fast  algorithms  to  test  for  deadlock.  If  there  is  a 
large  number  of  units  of  the  resource  then  Algorithms  3.8  and 
3.9  can  be  used  to  detect  deadlock  in  time  independent  of  the 
number  of  units.  If  there  is  a  large  number  of  processes  then 
Algorithm  3.10  can  be  used  to  detect  deadlock  in  time 
independent  of  the  number  of  processes. 
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1.  Do  for  each  node  Q  on  the  list  of  sinks; 

2.  Do  for  each  father  F  of  Q; 

3.  Decrement  the  wait  count  of  F  by  1 ; 

4.  If  the  wait  count  of  F  is  zero  then 

5.  Add  F  to  the  list  of  sinks; 

6.  End; 

7.  End; 

8.  Cycles  -  (Not  all  nodes  are  now  sinks) ; 

Algorithm _ J.  3  Determination  of  whether  a  directed  graph 

contains  a  cycle.  Maximum  execution  time  is  proportional  to 
the  number  of  edges  E  in  the  graph. 


/♦Switch  C  will  tell  if  node  P  is  in  a  cycle.*/ 

1.  Set  switch  C  to  say  node  P  is  not  in  a  cycle; 

2.  Initialize  a  list  to  contain  only  P; 

3.  Do  for  each  node  Q  on  list  while  C  says  P  is  not  in  a 

cycle ; 

4.  Do  for  each  sen  S  of  Q; 

5.  If  S  =  P  then 

6.  Set  switch  C  to  say  node  P  is  in  a  cycle; 

7.  If  S  has  not  yet  been  added  to  list  then 

'  8.  Add  S  to  end  of  list; 

9.  End; 

10.  End; 

Algorithm _ ,3.4  Determination  of  whether  node  P  is  in  a  cycle. 

Maximum  execution  time  is  proportional  to  the  number  of  edges 
E  in  the  graph. 
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1-  Do  for  each  node  Q  on  list  of  sinks; 

2.  Do  for  each  father  F  of  Q; 

If  F  is  not  already  on  list  of  sinks  then 
4-  Add  F  to  list  of  sinks; 

5.  End; 

6.  End; 

7.  Knots  =  (Not  all  nodes  are  now  sinks) ; 

Algorithm  3. 5  Determination  of  whether  a  directed  graph 
contains  a  knot.  Maximum  execution  time  is  proportional  to 
the  number  of  edges  E  in  the  graph. 


/♦Switch  D  will  tell  if  p  is  dead  locked.  */ 

1.  Set  switch  D  to  say  P  is  deadlocked; 

2.  Initialize  a  list  to  contain  only  P; 

3.  Do  for  each  node  Q  on  list  while  D  says  P  is  deadlocked; 

4.  Do  for  each  son  S  of  Q; 

5.  If  S  is  a  sink  then 

6.  Set  switch  D  to  say  P  is  not  deadlocked; 

7.  If  S  has  not  yet  been  added  to  list  then 

8.  Add  S  to  end  of  list; 

9.  End; 

10.  End; 

Algorithm  3.6  Determination  of  whether  process  P  is  deadlocked 
following  a  request  by  P  for  units  which  are  not  available. 
This  algorithm  can  te  used  for  an  expedient  state  with  only 
single  unit  requests  for  reusable  resources  or  single  resource 
requests  for  consumable  resources.  Maximum  execution  time  is 
proportional  to  the  number  of  edges  E  in  the  graph. 
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1. 

Let  Q  be 

the  son  of 

the 

son  of 

P; 

2. 

Do  while 

Q  exists  an 

d  Q 

is  not 

p; 

3. 

Let  Q 

be  the  son 

of 

the  son 

of 

4. 

End ; 

5. 

Cycles  = 

(Q  is  P)  ; 

Algorithm  3.7  Determination  of  whether  node  P  is  in  a  cycle  in 
a  bipartite  graph  in  which  each  node  has  at  most  one  son. 
This  detects  if  process  P  is  deadlocked  in  a  resource 
allocation  system  with  single  unit  resources  and  single  unit 
requests.  Maximum  execution  time  is  proportional  to  min{mrn). 


1.  Point  to  beginning  of  list  of  processes; 

2.  Do  for  next  process  P  on  list  of  processes; 

3.  If  P  has  not  been  reduced  and  the  request  by  P  does 

not  exceed  the  available  units  then 

4.  Do ; 

5.  Add  units  allocated  to  P  to  available  units; 

6.  Mark  P  as  reduced; 

•  7.  Point  back  to  beginning  of  list  of  processes; 

8.  End; 

9.  End; 

10.  Deadlock  =  (Not  all  processes  are  now  reduced)  ; 

Algorithm _ J3.8  Detection  of  deadlock  in  a  resource  allocation 

with  a  single  type  of  resource.  This  is  a  simplification  of 
Algorithm  3.1  and  its  maximum  execution  is  proportional  to  n1 2 3 4 5 6 * 8 9 10. 
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1.  Do  for  each  process  P  on  list  to  be  reduced; 

2.  Add  units  allocated  to  P  to  available  units; 

3.  Do  for  each  process  Q  whose  request  can  now  be 

g  ranted ; 

4.  Add  Q  to  list  to  be  reduced; 

5.  End; 

6.  End; 

7.  Deadlock  =  (Not  all  processes  are  now  reduced) ; 

Algorithm _ 3^9  Detection  of  deadlock  in  a  resource  allocation 

system  with  a  single  type  of  resource.  This  is  a 
simplification  of  Algorithm  3.2  and  its  maximum  execution  time 
is  proportional  to  n. 


1.  Sum  =  HO; 

2.  Do  j  =  1  to  t  while  (Sum  >  j) ; 

3.  Sum  =  Sum  ♦  Hj; 

4.  End; 

5.  Deadlock  =  ( j  <  t) ; 

Algorithm _ 3.J0  Detection  of  deadlock  in  a  resource  allocation 

system  with  a  single  type  of  resource.  Maximum  execution  time 
is  proportional  to  the  total  units  t  of  the  resource. 
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3.7  Collier^s  and  Shoshani * s  Graphs 

In  this  section  we  establish  the  relationship  between 
reusable  resource  systems  and  the  graph  models  of  resource 
allocation  given  by  Collier  and  Shoshani. 

Braude  [1961]  gave  a  model  of  resource  allocation  for 
single  unit  resources  which  was  subsequently  described  in 
terms  of  directed  graphs  by  Collier  [1968].  As  given  by 
Collier,  there  is  a  node  in  the  graph  for  each  process  and  an 
edge  is  drawn  from  node  Pi  to  Pj  when  Pi  has  requested  a 
resource  which  has  been  allocated  to  Pj. 

Shoshani  [1969a]  has  given  a  graph  model  of  resource 
allocation  for  the  general  case  of  multiple  unit  resources. 
In  Shoshani* s  model  there  is  a  node  for  each  resource,  and  an 
edge  is  drawn  from  node  Ri  to  node  Rj  when  a  process  has  been 
allocated  some  units  of  Ri  and  has  requested  some  units  of  Rj. 
(Actually,  Shoshani  draws  the  edge  only  when  the  request  for 
Rj  can  not  be  granted.  8e  slightly  alter  his  graph  by  drawing 
the  edge  even  when  the  request  for  Rj  can  be  granted.) 

Let  us  define  the  square  of  a  directed  graph  G  as  a 
directed  graph  which  has  the  same  nodes  as  G  and  which  has  an 
edge  (Q1,Q3)  for  each  path  of  length  two,  (Q1,Q2,Q3),  in  G. 
In  Figure  3.6(a)  we  show  a  reusable  resource  graph;  in  parts 
(b)  and  (c)  of  that  figure  are  the  square  of  that  graph.  From 
the  definitions  of  "square”  and  "bipartite"  it  is  obvious  that 
in  the  square  of  a  bipartite  graph  there  are  edges  directed 
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only  between  nodes  within  subset  PI  or  within  subset  RHO. 
Thus,  the  square  of  a  bipartite  graph  is  really  two  separate 
subgraphs,  which  can  be  labelled  PI  and  RHO.  As  is 
illustrated  in  Figure  3.6,  the  square  of  a  reusable  resource 
graph  is  two  graphs;  the  PI  graph  is  Colliers  graph  and  the 
RHO  graph  is  Shoshani’s  graph. 

Clearly,  a  reusable  resource  graph  contains  all  the 
information  represented  in  Collier’s  graph  or  in  Shoshani’s 
graph.  On  the  other  hand,  neither  of  their  graphs  give  the 
information  needed  to  fully  describe  the  system  state.  Their 
graphs  do  not  completely  describe  what  causes  interactions 
between  the  processes  and  can  not  be  used  for  deadlock 
detection  in  the  general  case. 

The  following  lemma  can  be  proved  from  the  definitions  of 
bipartite  graph  and  cycle: 

The  PI  (or  RHO)  subgraph  of  the  square  of  a  bipartite 
graph  contains  a  cycle  if  and  only  if  the  bipartite  graph 
contains  a  cycle. 

Using  this  lemma,  we  can  restate  Theorems  3.2(1)  and  3.3  to 
apply  to  Collier’s  or  Shoshani’s  graphs.  While  Collier 
asserted  that  a  cycle  in  his  graph  (with  only  single  unit 
resources)  is  a  necessary  and  sufficient  condition  for 
deadlock,  his  assertion  was  based  on  intuitive  notions  of 
operations  and  deadlock.  Using  definitions  of  operations  and 
deadlock  based  on  a  matrix  model  of  resource  allocation, 
Shoshani  gave  part  (1)  of  Theorem  3.2  and  Theorem  3.3  as 
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applied  to  his  graph. 

In  summary,  we  have  shown  that  the  model  of  reusable 
resource  systems  with  Theorems  3.2,  3.3,  and  3.4  includes  and 


extends  Collier’s  and  Shoshani’s  work  on  graph  models 
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(a)  Reusable  resource  (b)  Collier’s  graph  (c)  Shos’na  ni  '  s  graph 

graph 


3-_6  Reusable  resource  graphs  compared  with  the  graphs 

i 

of  Collier  and  Shoshani.  When  graph  (a)  is  squared  (paths  of 
length  two  become  edges  and  the  original  edges  are  deleted), 
graphs  (b)  and  (c)  are  formed. 
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3.8  Recovery  from  Deadlock 

Once  processes  in  a  reusable  resource  system  have  become 
deadlocked  they  will  remain  deadlocked  until  some  "external 
force",  such  as  the  operating  system  or  the  operator, 
intervenes.  Ihe  intervention  must  violate  the  usual  rules  by 
which  the  processes  interact  -  otherwise  the  deadlock  can  not 
be  removed.  The  obvious  types  of  intervention  are  either  to 
terminate  some  processes  or  to  pre-empt  some  of  the  allocated 
resources  until  the  deadlock  is  removed.  When  a  deadlocked 
process  is  either  terminated  or  has  enough  resources 
pre-empted  from  other  processes  so  that  it  is  no  longer 
blocked,  then  we  say  the  process  is  liberated .  Once  enough 
processes  have  been  liberated  so  that  no  processes  are 
deadlocked,  then  we  say  the  system  has  recovered  from 
deadlock.  Of  course  it  is  not  usually  necessary  to  liberate 
all  deadlocked  processes  in  order  to  recover  from  deadlock;  in 
many  cases  it  is  sufficient  to  liberate  only  one  process  in 
order  to  make  all  processes  not  deadlocked. 

Minimum  Cost  Recovery 


We  can  associate  a  cost  with  the  liberation  of  each 
process.  If  the  process  is  a  user's  job,  then  the  cost  of 
terminating  the  job  may  be  the  cost  of  restarting  the  job  and 
running  it  again  to  the  point  at  which  it  was  terminated. 


This  cost  of  liberation  could  easily  be  calculated  from  the 
accounting  records  for  the  job.  Alternately,  an  arbitrary 


cost  for  terminating  jobs  could  be  set  by  the  systems 
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programming  staff;  for  example,  the  systems  programming  staff 
could  set  the  cost  of  terminating  a  student  job  to  one  dollar, 
the  cost  of  terminating  a  scientific  job  to  ten  dollars,  and 
the  cost  of  terminating  a  systems  job  to  one  hundred  dollars. 

If  a  process  is  liberated  by  pre-empting  resources  from 
other  processes  then  it  may  be  reasonable  to  figure  the 
liberation  cost  per  unit  pre-empted,  according  to  the  type  of 
resource  pre-empted.  This  approach  has  been  taken  by 
Shoshani,  and  he  has  given  an  algorithm  to  determine  the 
minimum  cost  of  recovery  from  deadlock  [Shoshani  1969a]. 
Algorithm  3.11  is  similar  to  Shoshani*s  algorithm,  the  main 
difference  being  that  the  cost  of  liberating  a  process  is  not 
given  explicitly  in  Algorithm  3.11.  Thus  Algorithm  3.11  will 
find  the  minimum  cost  of  recovery  from  deadlock  for  arvy 
(computable)  function  giving  the  cost  of  liberating  a  process. 

Algorithm  3.11  uses  a  list  of  states,  each  partially 
reduced  versions  of  the  original  deadlocked  state  S.  With 

t 

each  state  is  associated  a  recovery  cost  which  is  the  total  of 
the  costs  of  liberating  processes  for  that  state. 

In  terms  of  the  reusable  resource  graph,  if  the  liberated 
process  is  terminated  then  all  edges  to  or  from  the  process 
node  are  deleted.  If  resources  are  pre-empted  to  liberate  the 
process  then  all  the  process* s  request  edges  become  assignment 
edges,  and  processes  from  which  units  are  pre-empted  have  some 
of  their  assignments  changed  to  requests.  These  are  the 
changes  in  the  system  state  which  take  place  in  statement  6  of 
Algorithm  3.11.  (Shoshani*s  description  of  this  algorithm  has 
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a  minor  error  in  that  it  omits  assigning  the  preempted 
resource  to  the  liberated  process.) 

In  statements  7  and  8  the  cost  of  liberating  the  process 
is  added  to  the  cost  thus  far  accumulated  in  recovering  from 
deadlock  for  that  state,  and  the  state  is  inserted  into  the 
list  of  states  in  order  of  increasing  recovery  cost.  The 
advantage  of  maintaining  the  states  in  order  of  cost  of 
recovery  is  that  the  first  state  to  be  completely  reduced  is 
guaranteed  to  have  the  minimum  cost  of  recovery;  this  is 
because  its  total  cost  of  recovery  is  less  than  or  equal  to 
the  partial  cost  of  recovery  of  each  remaining  state  on  the 
list.  We  do  not  give  a  more  complete  description  of  the 
operation  of  the  algorithm  because  Shoshani  has  already  done 


so. 


When  the  deadlock  is  of  a  complicated  nature.  Algorithm 
3. 1 1  will  require  a  very  large  quantity  of  execution  time  and 
storage  space.  Consider  a  system  containing  n  processes  and 
an  equal  number  m  of  single  unit  resources.  Let  the  cost  of 
pre-empting  all  units  be  the  same.  Suppose  that  for  1  <  i  < 


n, 


the  unit  of  Ri  is  assigned  to  process  Pi  and  that  Pi 


requests  all  resources  except  Ri;  in  the  resulting  state,  let 
us  call  it  S,  all  processes  are  deadlocked.  If  Algorithm  3.11 
is  applied  then  for  the  original  deadlock  state  S,  Do-group  5 
will  create  a  generation  of  n  new  states,  one  for  each 
deadlocked  process.  Unfortunately,  in  state  S,  liberating  a 
process  does  not  allow  any  reductions  other  than  the  liberated 
process.  Thus,  for  each  of  the  n  states  in  the  first 
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generation ,  Do— group  5  will  create  n-1  states,  one  for  each 
remaining  deadlocked  state.  Continuing  in  this  manner,  for 
each  of  the  n  *  (n-1)  ♦  ...  +  (n  -  k  +  1)  states  in  the  k-th 
generation,  n  -  k  states  will  be  created.  In  all,  Dc-group  5 
will  be  executed  on  the  order  of  n  +  n (n  -  1)  ♦  ...  +  n! 
times.  Since  each  execution  of  Do-group  5  requires  on  the 
order  of  n  operations  to  liberate  a  process,  the  execution 
time  of  the  algorithm  is  on  the  order  of  n (n  ♦  n (n  -  1)  ♦  ... 
♦  n!}.  This  estimation  of  execution  time  has  ignored  Do-group 
3  because  Do-group  3  is  executed  once  for  each  state  created 
by  Do-group  5,  and  each  execution  of  statement  4  in  Do-group  3 
requires  on  the  order  of  n  operations. 

While  it  is  not  necessary  to  maintain  that  part  of  the 
list  of  states  which  has  been  used  in  Do-group  3,  n!/2  states 
must  be  on  the  list  at  the  time  a  state  is  finally  completely 
reduced.  This  number  of  states  results  from  the  fact  that 
there  are  nl/2  different  ways  to  arrange  the  first  n-2 

i 

processes  which  are  liberated.  (The  first  complete  reduction 
will  occur  when  n-1  process  have  been  liberated.)  Even  though 
in  the  last  states  on  the  list  most  of  the  processes  have  been 
reduced,  the  obvious  representation  of  a  state  will  still 
require  at  least  n  words;  thus  the  algorithm  will  require  on 
the  order  of  n(n!)  words  of  storage. 

In  summary,  we  have  shown  that  Algorithm  3,11  can  require 
execution  time  proportional  to  n(n  *  n(n  -  1)  ♦  ---  ♦  n!)  and 
storage  space  proportional  to  n(n!)-  This  large  amount  of 
storage  space  means  that  for  systems  with  more  than  about  5 
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processes  and  5  resources.  Algorithm  3-11  is  probably  not  of 
practical  value-  Algorithm  3-11  does  not  take  advantage  of 
the  "structure”  of  a  deadlock;  for  example,  it  in  no  way 
searches  for  cycles  or  knots  and  tries  to  eliminate  them. 
Although  the  author  has  not  developed  a  smaller  and  faster 
algorithm  equivalent  to  Algorithm  3-11,  he  suspects  that  such 
an  algorithm  exists. 

Minimum  Cost  Recovery  with  Single  Onit  Requests 

It  is  interesting  that  if  the  reusable  resource  system 
uses  single  unit  requests  then  there  is  an  algorithm, 
requiring  maximum  time  and  maximum  space  proportional  to  N2, 
which  finds  the  minimum  cost  recovery  (N  =  m  *  n  is  total 
number  of  nodes  in  the  reusable  resource  graph.) 

The  algorithm  depends  (1)  upon  the  fact  that  in  an 
expedient  state  with  single  unit  requests,  a  knot  is  a 
necessary  and  sufficient  condition  for  deadlock,  and  (2)  upon 
the  following  lemma. 

In  a  directed  graph,  if  the  edges  directed  from  one  node 
in  each  knot  are  deleted,  then  the  graph  no  longer 
contains  a  knot. 

The  lemma  is  proved  by  observing  that  the  nodes  from  which  the 
edges  were  directed  become  sinks,  and  that  there  are  paths 
starting  at  all  nodes  previously  in  knots  which  lead  to  these 
new  sinks-  From  this  lemma  we  can  infer  that  liberating  one 
process  in  each  knot  will  remove  all  deadlocks. 

Given  a  list  of  knots  in  the  expedient  reusable  resource 
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graph,  all  that  is  needed  to  find  the  minimum  cost  for 
recovery  is  to  locate  the  one  node  in  each  knot  which  has  the 
smallest  liberation  cost.  Finding  the  node  with  the  smallest 
liberation  cost  in  a  knot  can  be  accomplished  by  a  single  scan 
of  the  nodes  in  the  knot. 


We 

will  now  outline  a  method  of  finding  the  knots  with 

maximum 

execution  time  proportional  to  N2.  This  method  will 

not  be 

given  in  detail  because  it  is  described  by  Purdom 

[  1968], 

who  gives  its  required  execution  time  and  storage 

space. 

Purdora’s  method  is  part  of  a  larger  algorithm  which 

finds  the  "transitive  closure”  of  a  directed  graph.  His 


method 

provides  considerably  more  information  than  just 

finding 

the  knots:  it  also  finds  all  the  path  equivalence 

classes. 

He  defines  two  nodes  to  be  path  equivalent  (or 

simply , 

equivalent)  if  each  is  on  a  path  starting  at  the 

other,  or  if  the  two  nodes  are  identical.  A  path  equivalence 
class  (or  simply,  an  equivalence  class)  is  the  set  of  all 
nodes  which  are  path  equivalent  to  some  particular  node. 


Purdom  *  s 

method  works  in  a  top  down  manner,  proceeding  son  to 

to  son 

to  son  until  a  node  on  a  path  is  repeated.  When  this 

occurs , 

the  method  has  detected  a  cycle;  the  cycle  is  removed 

by  collecting  all  nodes  in  the  cycle  into  one  super  node  which 
has  edges  to  and  from  it  for  all  edges  directed  to  or  from  its 
constituent  nodes.  This  method  continues  removing  cycles  and 
building  super  nodes  until  the  graph  contains  no  cycles.  The 
result  is  a  graph  without  cycles  in  which  the  nodes  are  the 
equivalence  classes  of  the  original  graph.  An  edge  is 
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directed  from  one  equivalence  class  to  another  exactly  when 
the  original  graph  has  an  edge  directed  from  a  node  in  the 
first  equivalence  class  to  a  node  in  the  second  equivalence 
class. 

To  locate  knots  in  an  expedient  reusable  resource  graph, 
we  first  reduce  the  graph  as  far  as  possible.  Next,  Purdora’s 
method  is  used  to  produce  a  graph  whose  nodes  are  the 
equivalence  classes  of  the  original  graph.  He  need  consider 
only  the  equivalence  classes  which  contain  at  least  two 
members  and  which  are  sinks;  these  equivalence  classes  are  the 
knots  in  the  original  bipartite  graph  because  (1)  each  node  in 
such  an  equivalence  class  has  a  path  from  it  to  each  other 
node  in  the  equivalence  class,  and  (2)  since  the  equivalence 
class  is  a  sink,  there  is  no  path  to  a  node  outside  the 
equivalence  class. 

To  find  the  minimum  cost  of  recovery  when  there  are 
single  unit  requests,  first  the  resource  allocation  graph  is 
reduced  as  far  as  possible.  Next,  Purdom's  method  locates  the 
knots  and  finally  the  least  costly  process  to  liberate  in  each 
knot  is  located.  Since  each  step  in  this  sequence  requires 
maximum  execution  time  and  storage  space  proportional  to  N2, 
then  so  does  the  whole  sequence. 

A  Practical  Method  of  Recovery 

As  we  have  seen,  finding  the  minimum  cost  recovery  from 
deadlock  can  be  guite  a  complicated  undertaking,  and  while 
such  methods  are  of  theoretic  interest,  a  practical  system 
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will  probably  make  belter  use  of  simpler  techniques.  We  now 
present  a  very  simple  method  which  finds  a  good  recovery  from 
deadlock,  though  not  necessarily  at  minimum  cost. 

Let  us  suppose  that  the  processes  will  be  liberated  by 
being  terminated,  and  that  the  processes  are  divided  into 
classes  where  the  cost  of  terminating  any  process  in  the  i-th 
class  is  Ci.  Algorithm  3.12  takes  the  obvious  approach  of 
terminating  processes  in  the  lowest  cost  class,  then  in  the 
next  higher  cost  class,  and  so  on,  until  all  deadlocks  are 
removed.  Of  course,  after  each  termination,  the  reusable 
resource  graph  is  reduced  as  far  as  possible  in  order  to  avoid 
terminating  processes  when  this  could  not  possible  help  the 
recovery.  This  method,  as  given  by  Algorithm  3-12,  is  optimal 
in  that  no  processes  with  termination  cost  Ci  or  greater  will 
be  terminated  unless  this  is  absolutely  necessary  to  recover 
completely  from  the  deadlock.  Suppose  there  are  three  classes 
of  processes  in  the  system,  student  jobs,  scientific  jobs,  and 

i 

systems  jobs,  and  that  these  classes  are  in  order  of 
increasing  termination  cost  as  given-  Algorithm  3.12  will 
find  a  deadlock  recovery  which  terminates  only  student  jobs, 
if  such  a  recovery  exists,  and  will  not  terminate  a  scientific 
or  a  systems  job  unless  this  is  absolutely  necessary. 
Algorithm  3.12  executes  in  maximum  time  proportional  to  m  n 
because  (1)  Do-groups  1  and  3  are  executed  at  most  n  times, 
and  {2)  the  complete  reduction  of  the  graph  (accomplished  by 
Algorithm  3.2  in  statement  5)  requires  at  most  m  n  operations. 
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Fast  Recovery  for  Continuous  Deadlock  Detection 

If  a  knowledge  is  continuously  maintained  of  whether  the 
system  is  deadlocked,  then  there  is  a  very  simple,  though  not 
necessarily  optimal,  method  of  recovering  from  deadlock.  A 
state  S  which  is  not  deadlocked  can  change  to  a  deadlock  state 
T  only  if  a  process,  call  it  Pi,  executes  a  request  which  can 
not  be  granted.  Since  S  is  completely  reducible,  if  we 
liberate  Pi  in  T,  then  T  will  be  completely  reducible.  Thus, 
the  recovery  consists  simply  of  liberating  Pi.  If  the 
liberation  costs  of  all  processes  are  identical  then  this 
simple  method  is  optimal.  (Recovery  methods  similar  to  this 
have  been  suggested  by  Murphy  [  1968]  and  Collier  [  1968  ]). 
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/♦Minimum  recovery  cost  will  be  recovery  cost  of  */ 

/♦the  only  completely  reduced  state.*/ 

1.  Set  the  recovery  cost  of  S  to  zero; 

2-  Initialize  the  list  of  states  to  contain  only  S; 

3.  Do  for  each  state  T  on  list  of  states  while  no  state 
has  been  completely  reduced; 

4-  Use  Algorithm  3-2  to  reduce  T  as  far  as  possible; 

5-  Do  for  each  process  P  which  is  deadlocked  in  T; 

6-  Create  state  U  from  T  by  liberating  P; 

7-  Set  recovery  cost  of  U  to  recovery  cost  of  T 

plus  cost  of  liberating  P; 

8-  Add  U  to  the  list  of  states  ordered  by 

recovery  cost; 

9.  End; 

10.  End; 

Algorithm  3-  1  1  Finding  the  minimum  cost  of  recovery  from 
deadlock  in  state  S-  Maximum  execution  time  is  proportional 
to  n  (n  «■  n  (n  -  1)  ♦  ...  +  n!)  when  m  =  n. 


1-  Do  for  each  process  P  on  list  of  processes  ordered  by 

increasing  termination  cost; 

2-  If  P  has  not  been  reduced  then 

3-  Do; 

4-  Terminate  process  P; 

5.  Use  Algorithm  3-2  to  reduce  as  many  processes 

as  possible; 

6.  End; 

7-  End; 

Algorithm _ 3-_ J 2  A  fast  method  of  deadlock  recovery.  Maximum 


execution  time  is  proportional  to  ran. 


SECTION  3.9 


103 


3.9  Deadlock  Prevention 


Up  to 

this 

point  we 

have 

been  concerned  with 

how 

deadlocks 

can  be 

detected 

once 

they  have  occurred.  In 

this 

section  we 

discuss 

methods  o 

f  guaranteeing  that  deadlocks 

can 

not  occur.  The  following  definition,  which  is  not  necessarily 
restricted  to  reusable  resource  systems,  formalizes  the  idea 
of  deadlock  prevention. 

A  deadlock  prevention  policy  is  a  rule  which  eliminates 
some  of  the  operations  of  a  system,  thereby  creating  a  new 
system  which  has  one  or  more  safe  states. 

(Recall  that  in  Section  2.2,  a  safe  state  was  defined  to  be  a 
state  from  which  the  system  can  not  reach  a  deadlock  state.) 
Figure  3.7  gives  an  example  of  a  deadlock  prevention  policy 
applied  to  a  system  which  is  not  a  resource  allocation  system. 

One  Process  At  A  Time 

One  of  the  most  obvious  ways  to  prevent  deadlock  is  to 
allow  only  one  process  at  a  time  to  be  allocated  resources; 
this  policy  may  leave  the  resources  of  the  system  idle  much  of 
the  time,  and  it  should  be  used  only  when  no  other  prevention 
policy  is  practical  and  deadlock  is  prohibitively  expensive. 
This  prevention  policy  eliminates  all  acquisition  operations 
except  acquisitions  occurring  when  no  allocations  have  been 
made  or  when  allocations  have  been  made  only  to  the  acquiring 
process.  This  policy  has  the  advantage  that  it  places  no 
restrictions  on  the  behavior  of  the  processes,  and  requires  no 
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advance  knowledge  of  the  behavior  of  the  processes;  that  is, 
no  request  or  release  operations  are  eliminated  by  the  policy, 
A  deadlock  prevention  policy  which  eliminates  only 
acquisition  operations  will  be  called  an  acquisition  policy, 
ae  will  call  an  acquisition  policy  optimal  if  there  is  no 
other  acquisition  policy  which  eliminates  fewer  acquisitions, 
We  can  easily  prove  the  lemma: 

In  a  reusable  resource  system  the  optimum  acquisition 
policy  allows  only  one  process  at  a  time  to  be  allocated 
resources. 

This  lemma  follows  from  the  observation  that  if  two  or  more 
processes  have  been  allocated  resources,  a  deadlock  will  occur 
if  each  process  reguests  all  units  not  allocated  to  it. 

Collective  Bequests 

Another  obvious  way  to  prevent  deadlock  is  to  restrict 
each  process  so  that  it  can  make  a  request  only  when  no 

i 

resources  have  been  allocated  to  it.  This  policy  prevents 
deadlock  because  processes  with  resources  allocated  to  them 
can  never  be  blocked,  and  thus  are  always  able  to  release 
resources  allocated  to  them.  Hence  it  is  always  possible  that 
a  process  which  is  blocked  will  acquire  its  requested 
resources.  Hhat  this  policy  implies  is  that  each  process  must 
collective! y  request  its  resources,  anticipating  its  future 
maximum  needs,  A  process  is  free  to  release  units  no  longer 
needed  until  all  acquired  units  are  released.  Then  the  process 
again  *  requests  collectively,  and  so  on.  The  disadvantage  of 
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this  policy  is  that  many  resources  are  acquired  long  before 
they  are  actually  needed,  and  thus  remain  idle  much  of  the 
time.  An  advantage  of  this  policy  is  that  no  restrictions  are 
placed  on  the  behavior  of  the  resource  allocator;  that  is,  no 
acquisition  operations  are  eliminated  by  the  policy. 

Ordered  Resources 

Havender  [1968],  Collier  [1968],  and  Shoshani  [1969a] 
have  listed  methods  of  preventing  deadlock,  including  the  two 
methods  given  above.  Havender  presents  a  policy,  which  we  will 
call  the  ordered  resources  policy  ,  which  is  used  to  prevent 
deadlock  while  allocating  core,  data  sets,  and  physical 
devices  to  job  steps  in  OS/360. 

The  ordered  resources  policy  partitions  the  resources 
into  k  classes,  numbered  1,2,...,k.  A  process  is  allowed  to 
request  units  of  a  resource  in  class  i  only  if  no  units  of 
resources  in  classes  i,  i+1,  ...,  or  k  have  already  been 
allocated  to  the  process.  If  there  is  only  one  class  of 
resources,  this  policy  becomes  identical  to  the  previous 
policy  requiring  collective  requests. 

The  ordered  resources  policy  prevents  deadlock  because 
any  process  holding  units  of  a  class  k  resource  can  not  be 
blocked  and  thus  is  able  to  release  all  its  units.  Any  process 
holding  units  of  a  class  k- 1  resource  can  request  units  only 
in  class  k  [which  can  eventually  be  released)  and  thus  can 
receive  its  request  and  can  eventually  release  any  resources 
it  holds.  Continuing  by  induction,  any  process  holding 
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resources  of  any  class  can  eventually  receive  its  request. 
Another  way  of  showing  that  this  policy  prevents  deadlock  is 
to  observe  that  ordering  the  resources  prevents  the  reusable 
resource  graph  from  containing  a  cycle,  which  is  a  necessary 
condition  for  deadlock. 

The  ordered  resources  policy  offers  the  same  advantages 
and  disadvantages  as  the  policy  of  collective  requests,  with 
the  improvement  that  a  process  can  defer  for  a  time  its 
requests  for  resources  in  the  higher  classes. 

The  resources  of  the  highest  class  (class  k)  need  be 
requested  only  when  actually  needed,  and  can  be  released  as 
soon  as  they  are  no  longer  needed.  Hence,  the  resources  of  the 
highest  class  will  be  used  most  efficiently,  and  the  most 
valuable  resources  of  the  system  should  be  assigned  to  this 
class.  Resources  of  the  next  highest  class  will  be  held  by  a 
blocked  process  only  when  the  process  is  waiting  for  resources 
of  the  highest  class.  Thus  the  next  to  most  valuable  resources 


should  be  assigned  to  the  next  to  highest  class,  and  so  on. 

One  interpretation  of  the  ordered  resource  policy  is  that 
the  requests  and  releases  of  resources  must  be  nested  in  the 
order  of  the  classes.  In  each  process  between  a  request  for  a 
class  k  resource  and  the  release  of  all  class  k  resources, 
there  can  not  appear  any  reguests.  Between  a  request  for  a 

resource  and  the  release  of  all  class  k  and  k— 1 


class  k- 1 


resources. 


resources. 


the  only  requests  which  can  occur  are  for  class  k 
In  general,  between  a  request  for  a  class  i 


resource  and  the  release  of  all  resources  of  class  i  or 
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greater,  the  only  reguests  which  can  occur  are  for  resources 
of  classes  greater  than  i. 


Claims  for  Maximum  Resource  Requirements 


Both  the  collective  request  policy  and  the  ordered 
resources  policy  require  that  each  process  must  be  able  to 
anticipate  its  maximum  future  resource  requirements.  He  will 
call  the  maximum  future  resource  requirements  for  a  process 
its  claim.  Using  claims,  Dijkstra  [1965a],  gives  a  method  for 
preventing  deadlock  in  systems  with  a  single  type  of  resource; 
this  method  is  extended  to  several  types  of  resources  by 
Haberraann  [1969].  We  will  present  a  proof  that  their  methods 
are  correct  and  are  optimal. 

We  define  the  claim  matrix  C  as  an  n  by  m  matrix  where 
Cij  gives  the  maximum  number  of  units  of  resource  Rj  which 
will  be  required  by  process  Pi.  We  require  that  0  <  Cij  <  tj. 
For  given  process  Pi,  we  reguire  that  Cij  >  0  for  at  least  one 
resource  Rj;  this  means  every  process  can  request  at  least  one 
unit  of  one  resource.  We  define  a  claim  limited  reusable 
resource  system  as  a  reusable  resource  system  from  which  has 
been  eliminated  each  state  S  such  that  for  some  process  Pi  and 
some  resource  Rj,  the  number  of  units  of  Rj  assigned  to  Pi  and 
requested  ty  Pi  exceeds  Cij.  Also  eliminated  from  the 
reusable  resource  system  are  any  operations  which  change  the 
state  to  or  from  an  eliminated  state. 

There  is  a  simple  way  to  represent  the  claim  matrix  in  a 
reusable  graph.  For  each  unit  of  resource  Rj  which  is  claimed 
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by  process  Pi,  but  has  been  neither  assigned  to  nor  requested 
by  Pi,  we  draw  an  edge,  which  will  be  called  a  claim  edge, 
from  node  Pi  to  node  Rj.  (Assume  the  edges  in  the  reusable 
resource  graph  each  represent  one  unit  of  a  resource,  i.e., 
assume  weighted  edges  are  not  being  used.)  To  differentiate 
between  reguest  edges  and  claim  edges,  both  of  which  are 
directed  from  process  nodes  to  resource  nodes,  the  claim  edges 
will  be  drawn  as  dotted  lines.  A  reusable  resource  graph,  as 
augmented  by  the  claim  edges,  will  be  called  a  claim  limited 
reusable  resource  graph. 

In  this  chapter  there  are  only  reusable  resources  (there 
are  no  consumable  resources) ,  and  so  claim  limited  reusable 
resource  systems  and  claim  limited  reusable  resource  graphs 
will  be  called,  simply,  claim  limited  systems  and  claim 
limited  graphs. 

In  Figure  3.8  we  illustrate  a  sequence  of  operations  by 
process  PI  in  a  claim  limited  system.  In  the  system,  each 

i 

process  claims  two  units  of  resource  FI.  The  operations  by  Pi 
are  a  request  for  two  units,  an  acquisition  of  two  units,  and 
a  release  of  one  unit.  The  request  operation  changes  some 
claim  edges  (dotted)  to  request  edges  (solid);  the  acquisition 
reverses  the  direction  of  request  edges  thereby  making  them 
into  assignment  edges;  and  the  release  changes  an  acquisition 
edge  into  a  claim  edge.  This  illustrates  the  important  fact 
that  if  one  ignores  the  dotted/solid  differences  and 
directions  of  the  edges,  the  claim  limited  graph  is  identical 
for  all  states  in  the  claim  limited  system. 
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To  avoid  deadlock  in  a  claim  limited  system,  one  must 
guarantee  that  even  though  all  processes  request  as  many 
resources  as  allowed  by  their  claims,  deadlock  will  not  occur. 
For  given  assignments  of  units  in  a  state,  the  most  that  the 
processes  can  request  is  the  case  where  all  claim  edges  are 
changed  to  request  edges.  Of  course,  the  state  with  all  claim 
edges  changed  to  request  edges  will  not  be  deadlocked  if  and 
only  if  it  is  completely  reducible. 

In  a  claim  limited  graph,  the  request  and  claim  edges  are 
really  the  same;  the  only  difference  between  them  is  that  they 
belong  to  different  subsets  of  the  set  of  edges.  For  this 
reason,  when  we  say  a  claim  limited  graph  is  completely 
reducible,  the  implication  is  that  claim  edges  are  considered 
equivalent  to  request  edges.  Anticipating  Theorem  3.6,  an 
acquisition  is  defined  to  be  safe  if  it  results  in  a  state 
whose  claim  limited  graph  is  completely  reducible. 

Theorem _ J3.6  For  a  claim  limited  reusable  resource  system 

the  optimum  acquisition  policy  eliminates  all  acquisitions 
which  are  not  safe. 

Proof  The  theorem  will  be  proved  by  showing  that  if  the 
acquisition  policy  allows  an  acquisition  which  is  not 
safe,  then  deadlock  can  occur,  and  that  if  only  safe 
acquisitions  are  allowed,  then  deadlock  can  not  occur. 
First,  let  us  assume  there  is  an  acquisition  policy  which 
allows  an  acquisition  which  is  not  safe.  We  will  prove 
that  deadlock  is  not  prevented  by  showing  that  there  is  a 
sequence  leading  from  any  state  whose  claim  limited  graph 
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is  not  completely  reducible  to  a  deadlock  state.  The  fact 
that  the  claim  limited  graph  can  not  be  completely  reduced 
means  that  there  is  a  subset  of  processes,  call  it 
PSUBSET,  such  that  no  process  in  the  subset  can  acquire 
all  or  its  claim  until  at  least  one  other  process  in  the 
subset  releases  some  resources.  The  sequence  of 
operations  leading  to  a  deadlock  state  is  as  follows. 
Each  process  in  PSUBSET  with  no  request  pending  executes  a 
request  operation  demanding  the  rest  of  its  claim.  Each 
process  with  a  request  pending  for  less  than  the  remainder 
of  its  claim  waits  till  it  is  not  blocked,  acquires  the 
requested  resources,  and  then  requests  the  remainder  of 
its  claim.  Since  the  acquisition  policy  has  (supposedly) 
prevented  deadlock,  there  must  be  a  sequence  of  operations 
including  all  these  operations.  In  the  state  at  the  end 
of  the  sequence,  each  process  in  PSUBSET  has  requested  the 
remainder  of  its  claims,  but  no  process  in  PSUBSET 

i 

released  any  resources-  Hence,  the  state  is  deadlocked. 
Therefore,  if  an  acquisition  which  is  not  safe  is  allowed, 
then  there  is  no  safe  state  in  the  system,  i.e.,  deadlock 
is  not  prevented- 

Me  now  prove  that  if  the  policy  allows  only  safe 
acquisitions,  then  deadlock  is  prevented.  This  will  be 
done  by  showing  that  in  the  resulting  system  (1)  any  state 
whose  claim  limited  graph  is  completely  reducible  is  not  a 
deadlock  state  and  (2)  any  change  of  state  from  a  state 
whose  claim  limited  graph  is  completely  reducible  leads  to 


SECTION  3-9  111 


a  similar  state*  °{1)  is  true  because  if  a  stat e's  claim 
limited  graph  is  completely  reducible  than  the  state's 
reusable  resource  graph  is  obviously  completely  reducible, 
and  this  is  a  sufficient  condition  for  the  state  not  to  be 
deadlocked-  (Actually,  it  is  necessary  to  prove  that 
after  applying  the  acquisition  policy,  complete 
reducibility  of  a  resource  allocation  graph  is  still  a 
sufficient  condition  for  the  state  not  to  be  deadlocked. 
This  proof  would  be  nearly  identical  to  the  proof  of 
Theorem  3-1)  (2)  is  true  because  request  and  release 
operations  can  not  increase  the  assignments  and  only  safe 
acquisitions  are  allowed.  Since  (1)  and  (2)  are  true,  any 
state  with  a  completely  reducible  claim  limited  graph  is 
not  a  deadlock  state  and  can  be  changed  only  to  similar 
states.  Therefore  such  states  are  safe  and  the 
acquisition  policy  prevents  deadlock. 

For  those  familiar  with  Habermann's  method  of  deadlock 
prevention,  his  method  allows  only  those  acquisitions  which 
result  in  a  system  state  from  which  there  is  a  ’’full  safe 
sequence”.  Habermann's  ”full  safe  sequence”  is  an  ordering  of 
the  processes  such  that  each  receives  and  then  releases  all  of 
its  claim.  A  full  safe  sequence  corresponds  exactly  to  a 
sequence  of  reductions  which  completely  reduces  the  claim 
limited  graph.  Thus,  Theorem  3.6  affirms  that  Habermann's 
method  prevents  deadlock  and  is  optimal.  Theorem  3.6  was 
proved  with  the  benefit  of  a  formal  definition  of  deadlock, 
which  was  not  present  in  the  proofs  given  by  Habermann 
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[  1967,  1969]. 

Theorem  3.6  establishes  the  close  relationship  between 
deadlock  detection  and  deadlock  prevention,  and  it  explains 
why  Algorithms  3.1  and  3.8,  which  detect  deadlock,  were  first 
published  as  prevention  algorithms.  This  relationship  is 
important  because  it  means  that  the  algorithms  we  have 
developed  to  detect  deadlock  in  reusable  resource  systems  can 
also  be  used  by  prevent  deadlock  in  claim  limited  systems. 
Deadlock  is  prevented  by  refusing  to  allow  those  acquisitions 
which  are  not  safe;  and  acquisitions  are  tested  for  safeness 
by  using  one  of  the  deadlock  detection  algorithms  to  see  if 
the  acquisition  leaves  a  claims  limited  graph  which  is 
completely  reducible. 

Lemmas  equivalent  to  the  following  lemma  have  been  given 
by  Dijkstra  [  1  965a]  and  Habermann  [  1969  ]. 

Lemma _ 3. 4  Suppose  the  claim  limited  graph  is  completely 

reducible,  ,  and  process  Pi  executes  an  acquisition.  The 
acquisition  is  safe  if  and  only  if  the  resulting  claim 
limited  graph  can  be  reduced  to  a  graph  which  can  be 
reduced  by  Pi. 

Proof  If  the  resulting  claim  limited  graph  can  not  be 
reduced  to  a  graph  which  can  fee  reduced  by  Pi,  then  it  is 
not  completely  reducible  and  the  acquisition  is  not  safe. 
Suppose  that  after  the  acquisition  the  claim  limited  graph 
is  reduced  to  graph  T  which  can  be  reduced  by  Pi.  The 
same  sequence  which  completely  reduced  the  claim  limited 
graph  before  the  acquisition  will  also  completely  reduce 
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T.  (The  sequence  will  have  deleted  from  it  those 
processes  whose  reductions  lead  to  T.)  After  the 
acquisition  the  claim  limited  graph  is  completely 
reducible,  and  thus,  the  acquisition  is  safe-  (Notice 
that  Lemmas  3.3  and  3.4  are  very  similar,  as  are  their 
proofs.  ) 

Lemma  3.4  allows  us  to  shorten  the  execution  of  the 
algorithms  which  determine  if  an  acquisition  is  safe  when  we 
know  that  all  previous  acquisitions  were  safe.  Of  course, 
this  will  always  be  the  case  when  an  acquisition  policy  is 
used  to  prevent  deadlock.  The  improvement  in  each  algorithm 
is  the  same  as  the  improvement  resulting  in  deadlock  detection 
when  a  constant  knowledge  of  deadlock  is  maintained.  That  is, 
when  an  algorithm  is  used  to  reduce  a  graph,  the  reductions 
can  be  stopped  as  soon  as  the  process  causing  the  change  of 
state  can  be  reduced;  see  Section  3.5  for  a  discussion  of 
these  improvements  as  applied  to  the  case  of  deadlock 
detection. 


If  the  system  has  single  unit  resources  or  a  single  type 
of  resource,  then  the  improvements  to  the  algorithms  will  be 
the  same  for  deadlock  detection  and  for  deadlock  prevention. 

Suppose  a  claim  limited  system  has  single  unit  resources 
and  uses  the  optimum  acquisition  policy.  If  an  acquisition  is 
not  safe  then  necessarily,  the  acquisition  must  introduce  a 
cycle  into  the  claim  limited  graph.  Since  an  acquisition  by 
process  Pi  only  changes  edges  directed  to  and  from  Pi,  any 
cycle  must  contain  node  Pi.  Therefore,  the  acquisition  is 
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safe  if  and  only  if  node  Pi  is  not  in  a  cycle  in  the  resulting 
claim  limited  graph.  Thus  Algorithm  3.4,  which  determines  if 
a  node  is  in  a  cycle,  should  be  used  to  see  if  the  acquisition 
is  safe. 

One  of  the  simplifications  to  the  algorithms  which  is 
possible  in  deadlock  detection  is  not  possible  in  deadlock 
prevention.  In  deadlock  detection,  we  can  enforce  single  unit 
requests,  thereby  making  deadlock  equivalent  to  a  knot  in  an 
expedient  reusable  resource  graph.  In  a  claim  limited  graph 
it  does  not  make  sense  to  allow  only  one  edge  (a  request  edge 
or  a  claim  edge)  to  be  directed  from  each  process  node;  this 
would  be  equivalent  to  allowing  each  process  to  claim  only  one 
unit  of  one  resource.  Even  when  there  are  only  single  unit 
requests,  there  will  usually  be  more  than  one  edge  directed 
from  some  of  the  process  nodes,  and  therefore  the  knot 
detection  algorithms  can  not  be  used  to  determine  if  an 
acquisition  is  safe. 

Claim  Limited  Systems  Which  Are  Safe 

If  the  sum  of  the  claims  of  all  the  processes  in  the 
system  does  not  exceed  the  total  units  of  the  system  then  it 
is  obvious  that  deadlock  can  not  occur.  In  such  a  system,  a 
prevention  policy  is  of  no  use,  because  all  states  are  safe 
even  before  any  operations  are  eliminated. 

What  is  not  so  obvious  is  that  in  some  systems  even 
though  the  sum  of  the  claims  exceeds  the  total  units,  deadlock 
still  can  not  occur.  The  simplest  example  of  this  is  the 
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system  consisting  of  two  processes  each  of  which  claim  the 
only  unit  of  the  only  resource.  In  this  system  there  is  only 
one  unit,  but  the  sum  of  the  claims  is  two.  Still,  all  states 
in  the  system  are  safe. 

A  more  interesting  example  is  the  system  consisting  of  a 
single  type  of  resource  containing  four  units  and  three 
processes  each  of  which  claim  two  units  of  the  resource.  Here 
the  sum  of  the  claims  is  six,  but  there  are  only  four  units. 
As  the  reader  may  verify,  as  many  as  two  processes  may  become 
blocked  in  this  system,  but  there  are  no  deadlock  states. 
Observations  of  this  type  result  in  the  lemma: 

Lemma _ A  claim  limited  system  with  a  single  type  of 

resource  has  safe  states  if  and  only  if  the  sum  of  the 
claims  is  less  than  n  ♦  t.  (t  is  the  total  units  of  the 
resource. ) 

Proof  Let  S  be  a  state  such  that  (1)  every  process  has  a 
request  for  at  least  one  unit,  and  (2)  there  are  zero 
available  units.  S  is  obviously  a  total  deadlock  state. 
Let  SUMC  be  the  sum  of  the  claims. 

The  lemma  will  be  proved  by  showing  that  (a)  SURC  <  n 
*  t  if  and  only  if  S  is  not  a  state  in  the  system  and  (b) 
S  is  not  a  state  in  the  system  if  and  only  if  there  are 
safe  states. 

First  we  prove  (a).  Let  us  assume  that  SUMC  <  n  ♦  t, 
which  is  equivalent  to  assuming  that  t  >  SOMC  -  n.  If  S 
is  a  state  in  the  system  then  parts  (1)  and  (2)  of  the 
definition  of  S  must  be  satisfied.  If  (1)  is  true  then 


SECTION  3.9  116 


each  process  has  .been  assigned  at  most  one  unit  less  than 

its  claim  and  thus  at  most  SUMC  —  n  units  can  be  allocated 

in  S.  Since  t  >  SUMC  -  n,  part  (2)  can  not  be  satisfied, 
and  hence,  if  SUMC  <  n  *  t,  then  S  can  not  be  a  state  in 
the  system.  Now  let  us  assume  that  SUMC  >  n  +  t.  With 
this  assumption  even  when  (1)  is  true,  (2)  can  still  be 
satisfied  because  t  <  SUMC  -  n.  Hence,  if  SUMC  >  n  ♦  t 
then  S  is  a  state  in  the  system. 

Now  we  prove  (b)  by  showing  that  S  is  a  state  in  the 
system  if  and  only  if  there  are  no  safe  states. 

Initially,  we  show  that  if  S  is  a  state  in  the  system 
then  no  state  is  safe.  It  will  suffice  to  show  that  if  S 
is  a  state  in  the  system,  then  it  must  be  that  for  any 

other  state  T,  either  T  is  a  deadlock  state  or  T  -*->  S. 

If  T  is  not  a  deadlock  state  then  T  is  completely 
reducible,  and  thus  T  -*->  U,  where  there  are  no  requests 
or  assignments  in  U.  But  then  U  —  *->  S  because  each 

i 

process  in  U  can  request  and  acquire  any  units  assigned  in 
S  and  then  reguest  any  units  requested  in  S.  Thus  T  -*-> 

S.  Hence,  any  state  T  other  than  S  is  either  deadlocked 
or  is  not  safe.  Therefore,  if  S  is  a  state  in  the  system 
then  no  state  is  safe. 

To  complete  the  proof  of  (b)  we  now  show  that  if  no 

state  is  safe  then  S  must  be  a  state  in  the  system.  If  no 
state  is  safe  then  at  least  one  state,  call  it  T,  must  be 
a  deadlock  state.  If  the  system  contains  deadlock  state 

T,  then  it  must  also  contain  state  S,  as  will  be  shown  by 


SECTION  3.9  117 


the  following  construction.  First,  let  T  be  reduced  as 
far  as  possible  to  state  U.  In  state  U,  some  process, 
call  it  Pi,  has  a  request  which  exceeds  the  available 
units.  Construct  state  V  such  that  U  and  V  are  identical 
except  that  any  available  units  in  D  become  assigned  to 
Pi,  and  the  request  by  Pi  in  U  is  decreased  by  the 
available  units  in  0.  As  a  result,  in  V  there  are  zero 
available  units.  In  state  V  each  process  is  either  an 
isolated  node  {because  it  was  in  the  sequence  of 
reductions  changing  T  to  D)  or  is  blocked  (because  it 
could  not  be  reduced  in  U) .  From  V  construct  another 
state,  which  will  satisfy  the  description  of  S,  by  letting 
each  process  which  is  not  blocked  in  V  request  at  least 
one  unit.  From  this  construction,  it  follows  that  if 
deadlock  state  T  is  a  state  in  the  system,  then  U,  V,  and 
S  are  also  states  in  the  system.  This  concludes  the 
proof. 

For  the  case  of  a  single  type  of  resource.  Lemma  3.5 
gives  us  a  very  simple  test  to  see  if  an  acquisition  policy  is 
required  to  prevent  deadlock.  The  lemma  means  that  deadlock 
is  possible  only  when  the  total  claims  are  at  least  n  more 
that  the  total  units. 

There  is  also  a  simple  test  to  see  if  a  system  with 
single  unit  resources  requires  an  acquisition  policy  to 
prevent  deadlock.  To  state  this  test  we  need  to  define  an 
"undirected  graph”  and  an  "undirected  cycle”. 

An  undirected  graph  is  a  pair  (Q,£)  where  Q  is  a  set  of 
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nodes  and  E  is  a  set  of  edges-  Each  edge  in  E  is  an 
unordered  pair  (a,b)  where  a  and  b  are  nodes  in  Q«  An 
uflflj£ggtgd  cycle  is  a  nonempty  sequence  of  unordered  edges 
in  E,  {(a,b),  (b,c)  ,  (r ,s),  (s,a)),  in  which  no  edge 
appears  more  than  once. 

An  undirected  graph  is  the  same  as  a  directed  graph  except 
that  its  edges  are  unordered  pairs;  thus  (a,b)  and  (b,a)  are 
equivalent  in  an  undirected  graph.  He  can  interpret  a 
directed  graph  to  be  an  undirected  graph  by  simply  ignoring 
the  ordering  of  the  nodes  in  the  edges.  An  undirected  cycle 
is  different  from  a  directed  cycle  in  that  (1)  the  members  of 
the  sequence  are  edges  instead  of  nodes  and  (2)  the  members  of 
the  sequence  can  appear  in  the  sequence  only  once. 
Requirement  (2)  is  imposed  so  that  pathological  cases  such  as 
{(a,b),  (b,a) )  will  not  be  considered  to  be  undirected  cycles. 

Recall  that  for  a  given  claim  limited  system,  all  states 
have  the  same  claim  limited  graph  if  the  direction  of  the 
edges  is  ignored.  Thus,  it  is  reasonable  to  speak  of  the 
(unique)  undirected  claim  limited  graph  for  the  system. 

Lemma _ 3_.6  A  claim  limited  system  with  single  unit 

resources  has  safe  states  if  and  only  if  the  undirected 
claim  limited  graph  contains  no  undirected  cycles. 

Proof  The  proof  parallels  the  proof  of  Lemma  3. 5  and  will 
not  be  given  in  full  detail.  If  there  is  an  undirected 
cycle  in  the  undirected  claim  limited  graph,  then  the 
edges  in  the  undirected  cycle  define  a  directed  cycle- 
Thus,  a  reusable  resource  graph  can  be  constructed  which 
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contains  a  directed  cycle,  a  sufficient  condition  for 
deadlock.  Conversely,  if  there  is  no  undirected  cycle, 
then  it  is  impossible  to  construct  a  directed  cycle,  a 
necessary  condition  for  deadlock. 

To  tell  if  deadlock  is  possible,  we  need  to  know  if  there  is 
an  undirected  cycle  in  the  claim  limited  graph.  Undirected 
cycles  can  be  efficiently  detected  by  a  method  similar  to 
Algorithm  3.3.  The  method  successively  deletes  each 
undirected  edge  (a,b)  such  that  a  *  b  and  either  a  or  b  is  not 
in  another  edge.  The  undirected  graph  contains  no  undirected 
cycles  if  and  cnly  if  all  edges  are  deleted. 

The  author  knows  of  no  simple  test  to  determine  if  a 
claim  limited  system  has  safe  states  in  the  general  case  of  a 
system  having  more  than  one  resource  and  multiple  units  within 
the  resources. 

In  this  chapter  we  have  confined  our  attention  to  systems 
in  which  the  only  interactions  among  processes  are  a  result  of 
the  sharing  of  reusable  resources.  It  was  shown  that  deadlock 
is  equivalent  to  the  Mnon-reducibilityM  of  the  directed  graph 
representing  the  system  state.  A  number  of  deadlock  detection 
and  prevention  algorithms  were  presented.  Recovery  from 
deadlock  and  prevention  of  deadlock  were  investigated. 
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(a)  The  system  before  (b)  The  system  after 

applying  the  prevention  applying  the  prevention 

policy,  policy. 

Figure  3. 7  Example  of  creating  safe  states  by  applying  a 

prevention  policy.  The  prevention  policy  removes  the 

operations  which  change  state  S  to  U  and  state  T  to  7,  thereby 

making  S  and  T  into  safe  sta tes- 


Figu re  3._8  Examples  of  changes  of  state  in  a  claim  limited 
system.  The  reusable  resource  graphs  have  been  embellished  by 
the  dotted  edges,  thereby  forming  claim  limited  graphs. 
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CHAPTER  4.  EXPLICIT  INTERACTION  OF  PROCESSES 

In  Chapter  3  we  investigated  systems  in  which  processes 
interact  implicitly  via  reusable  resources.  In  this  chapter  we 
investigate  systems  in  which  processes  interact  explicitly  via 
consumable  resources.  The  most  important  new  material  in  this 
chapter  is  a  simple  model  of  the  explicit  interactions  of 
processes  and  a  fast  algorithm  for  detecting  deadlock  in  the 
case  where  each  request  is  for  units  of  one  resource.  While 
others  have  investigated  deadlock  caused  by  implicit 
interactions  {reusable  resources) ,  this  is  the  first  formal 
investigation  of  deadlock  caused  by  explicit  interactions. 

4. 1  Consumable  Resource  Systems 

In  this  section  we  present  a  formal  model  of  systems  of 
processes  whose  only  interaction  is  via  consumable  resources. 
{See  Section  3.1  for  an  informal  discussion  of  consumable 
resources.)  This  model  will  be  analogous  to  the  reusable 
resource  systems  defined  in  the  previous  chapter.  We  define: 

A  consumable  resource  system  is  completely  characterized 

by 

{1)  a  nonempty  set  of  processes  PI= {P 1  $ P2,- • • ,  Pn) , 

{2)  a  nonempty  set  of  consumable  resources 

RHO= {R1,R2#...#Rm} ,  and 

{3)  for  each  consumable  resource  R  j  ,  a  nonempty  subset  of 

hich  will  be  called  the  producers  of  Rj» 


the  processes  w 
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In  this  chapter  the  only  type  of  resources  will  be  consumable 
resources  so  they  will  be  called,  simply,  resources. 

Consumable  Resource  Graphs 

Each  state  of  a  consumable  resource  system  is  represented 
by  a  bipartite  directed  graph,  which  is  called  a  consumable 
resource  graph.  The  disjoint  sets  of  nodes  of  the  graph  are 
PI=  {P1,P2,. .. ,Pn]  and  RHO=  {El ,R2,. . . , Rro} .  Each  edge  directed 
from  a  process  node  Pi  to  a  resource  node  Rj  is  called  a 
request  ed_ge  and  represents  a  request  by  process  Pi  for  one 
unit  of  resource  Rj.  An  edge  directed  from  a  resource  node  Rj 
to  a  process  node  Pi  is  called  a  producer  edge  and  indicates 
that  process  Pi  is  one  of  the  producers  of  resource  Rj. 
Associated  with  each  resource  node  Rj  is  a  nonnegative  integer 
rj  whose  value  is  the  number  of  available  units  of  Rj. 

Proceeding  more  formally,  the  set  of  states  SIGMA  of  a 
consumable  resource  system  is  the  set  of  all  consumable 
resource  graphs  for  the  system.  We  define: 

A  consumable  resource  graph  is  any  bipartite  directed 
graph  whose  disjoint  sets  of  nodes  are  PI= {P 1 , P2, . - . , Pn} 
and  8H0=  {R 1 , R2 , . . . ,Rm} ,  together  with  an  available  units 
vector  (r  1  ,r2 , .  .  .  ,  rm)  such  that 

(1)  for  a  given  resource  node  Rj,  there  is  a  producer  edge 
directed  from  Rj  to  process  node  Pi  if  and  only  if  Pi  is 
one  of  the  producers  of  Ri,  and 

(2)  each  element  rj  of  the  available  units  vector  is  any 
nonnegative  integer. 
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Since  this  definition  says  nothing  about  the  number  of  request 
edges  directed  from  process  nodes  to  resource  nodes,  any 
number  of  request  edges  may  be  present. 

Figure  4.1  gives  an  example  of  a  state  of  a  consumable 
resource  system.  In  the  figure,  square  nodes  represent 
process  nodes  and  round  nodes  represent  resource  nodes.  The 
fact  that  two  units  of  resource  R1  are  available  (rl  =  2)  is 
illustrated  by  drawing  two  "subnodes”  inside  the  node  for  Rl. 
Zero  subnodes  are  drawn  inside  node  R2  to  show  that  r2  -  0. 
These  subnodes  are  not  included  in  the  formal  definition  of 
consumable  resource  graphs  and  are  drawn  only  as  a  convenient 
way  to  picture  the  available  units  vector. 


Operations  in  a  Consumable  Resource  Syste 


m 


There  are  three  types  of  operations  in  a  consumable 
resource  system;  requests,  acquisitions,  and  releases.  These 
operations  will  be  defined  by  describing  the  changes  they 

t 

cause  in  the  consumable  resource  graph.  Essentially,  a 
request  adds  request  edges,  an  acquisition  deletes  request 
edges  and  decreases  the  available  units,  and  a  release 
increases  the  available  units.  For  system  state  S  and  T,  we 
def ine : 

Requests.  In  state  S  if  no  reguest  edges  are  directed 


from  node  Pi,  then 


S  -i->  T 


where  S  and  T  are  identical  except  that  in  T  there  are 
request  edges  directed  from  node  Pi. 
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Acquisitions.  In  state  S  if  there  are  request  edges 
directed  from  node  Pi,  and  for  each  resource  Rj,  rj  is  as 
large  as  the  number  of  request  edges  directed  from  Pi  to 
R j  ,  then 

S  -i- >  T 

where  S  and  T  are  identical  except  that  (a)  for  each 
resource  Rj,  rj  is  decreased  by  one  for  each  request  edge 
directed  from  Pi  to  Bj,  and  <b)  each  request  edge  directed 
from  Pi  is  deleted. 

Releases.  In  state  S  if  no  request  edges  are  directed 
from  node  Pi,  and  some  producer  edges  are  directed  to  Pi, 
then 

S  -i->  T 

where  S  and  T  are  identical  except  that  at  least  one 
resource  Rj  having  a  producer  edge  directed  from  it  to  Pi 
has  its  available  units  (rj)  increased. 

Notice  that  these  operations  do  not  change  the  producer  edges; 
they  only  change  request  edges  and  the  available  units  vector. 

The  definitions  of  "request"  and  "acq uisition"  are 
identical  for  reusable  systems  and  consumable  resource 
systems.  However,  there  is  an  important  implied  difference 
between  the  operations  for  the  two  systems.  In  a  reusable 
resource  system,  for  a  given  process  Pi  and  a  given  resource 
Rj,  the  number  of  assignment  edges  (Rj,Pi)  plus  the  number  of 
request  edges  (Pi,Bj)  can  not  exceed  the  total  units  tj  of  Rj. 
Thus,  in  a  reusable  resource  system,  there  is  a  maximum  number 
of  edges  that  can  be  added  by  a  request  operation.  By 
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contrast,  in  a  consumable  resource  system,  any  number  of 
request  edges  can  be  added  by  a  request  operation.  See  Figure 
4,2  for  examples  of  operations  in  a  consumable  resource 
system. 

From  the  definitions  of  these  operations  and  the 
definition  of  '’blocked1*  in  Section  2,2,  it  is  easily  shown 
that: 


Process 
node  Hj 
from  Pi 

Hj- 


_  «  » 
Pi  is 

such 

to  S j 


blocked  if  and  only  if  there  is  a 
that  the  number  of  request  edges 
exceeds  the  available  units  rj  of 


resource 

directed 

resource 


That  is,  the  only  time  a  process  is  blocked  is  when  it  has  a 
request  for  more  units  than  are  presently  available. 
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Pi 


R2 


t 


Zi2.ure_4_._1  Example  of  a  system  state  in  a  consumable  resource 
system.  The  available  resources  vector  is  r  =  (2,0).  Process 
PI  is  the  only  producer  of  Hi,  and  process  P 2  is  the  only 
producer  of  R2-  Process  P2  has  requested  three  units  of  HI. 
Since  only  two  units  of  R1  are  available,  process  P2  is 
blocked  - 


State  S  - 1-> 


State  T 


-2->  State  U  -1->  State  V 


Figure _ 4_. 2  Examples  of  operations  in  a  consumable  resource 

system-  The  system  consists  of  two_  processes  and  one 
resource.  Process  P2  is  the  only  -producer  of  resource  HI-  PI 
requests  two  units  of  HI,  then  P2  releases  three  units  of  Hi, 
making  4  units  available,  and  finally  PI  acquires  two  units  cf 
HI. 
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4.2  Graph  Redactions  and  Deadlock 

In  this  section  we  develop  a  necessary  and  sufficient 
condition  for  a  particular  process  to  be  deadlocked  in  a 
consumable  resource  system.  This  condition  will  be  given  in 
terms  of  manipulations  of  the  consumable  resource  graph;  these 
manipulations  will  be  called  “reductions”. 


Reductions 


In  order  to  define  reductions  we  need  a  special  symbol. 


OMEGA: 

OMEGA  is  a  symbol  such  that  for  any  integer  i,  OMEGA  >  i 
and  OMEGA  +  i  =  OMEGA  -  i  -  OMEGA. 

OMEGA  may  be  thought  of  of  as  an  "infinitely  large"  positive 
integer.  During  reductions  of  the  consumable  resource  graph 
we  will  allow  an  element  rj  of  the  available  resource  vector 
to  assume  the  value  of  OMEGA. 

He  define: 

A  consumable  resource  graph  can  be  reduced  by  any  process 
node  Pi  which  is  not  an  isolated  node  and  which  is  not 

blocked.  The  reduction  by  Pi 

(a)  decrements  the  available  units  r j  for  each 
resource  Rj,  by  the  number  of  request  edges  directed 

from  Pi  to  Rj, 

(b)  sets  rj  to  OMEGA  if  Pi  is  a  producer  of  Rj,  and 
<c)  deletes  all  edges  directed  to  or  from  Pi. 

We  say  the  consumable  resource  graph  is  comgletery 
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reducible  if  and  only  if  a  sequence  of  reductions  deletes 
all  edges  in  the  graph. 

A  reduction  by  Pi  can  be  thought  of  as  an  acquisition 
operation  by  Pi  (if  Pi  has  a  request  pending)  followed  by  a 
release  operation  in  which  Pi  releases  as  many  units  as 
possible. 

The  formal  definition  of  consumable  resource  systems 
requires  that  each  resource  Rj  must  have  a  nonempty  set  of 
producers,  and  thus,  each  resource  node  Ej  must  have  at  least 
one  edge  directed  from  it.  A  reduction  of  a  consumable 
resource  graph  may  delete  producer  edges.  Strictly  speaking, 
it  is  possible  for  a  reduction  to  leave  a  graph  which  is  not  a 
consumable  resource  graph,  because  the  reduction  may  delete 
the  only  producer  edge  directed  from  some  resource  node. 
However,  we  will  adopt  the  convention  that  a  resource  Hj  may 
have  an  empty  set  of  producers  if  rj  has  been  set  to  OMEGA. 
With  this  convention,  the  reduction  of  a  consumable  resource 
graph  always  results  in  a  consumable  resource  graph. 

Reductions  of  reusable  resource  graphs  and  reductions  of 
consumable  resource  graphs  differ  in  one  important  aspect.  A 
reduction  of  a  reusable  resource  graph  necessarily  leaves  each 
element  of  the  available  units  vector  at  least  as  large  as  it 
was  before  the  reduction.  By  contrast,  a  reduction  of  a 
consumable  resource  graph  may  decrease  some  elements  of  the 
available  units  vector.  For  example,  in  Figure  4.3,  state  S 
is  reduced  by  PI  to  obtain  state  T.  Before  the  reduction  one 
unit  of  resource  R2  is  available,  but  after  the  reduction. 
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zero  units  of  B2  are  available.  The  fact  that  a  reduction  can 
decrease  the  available  units  has  the  unfortunate  consequence 
that  the  order  of  reductions  becomes  important.  For  example, 
in  Figure  4.3  state  S  can  be  reduced  by  PI,  but  if  S  is 
reduced  first  by  P2  to  obtain  a  state,  call  it  V,  then  V  can 
not  be  reduced  by  PI.  Thus,  Lemma  3.2  does  not  apply  to 
consumable  resource  systems. 

Necessary  and  Sufficient  Conditions  for  Deadlock 

Se  now  state  a  necessary  and  sufficient  condition  for  the 
deadlock  of  a  particular  process. 

Theorem _ 4_.J[  Process  Pi  is  not  deadlocked  if  and  only  if  a 

sequence  of  reductions  leaves  a  state  in  which  Pi  is  not 
blocked. 

Proof  If  a  sequence  of  reductions  leaves  Pi  not  blocked 
then  Pi  is  not  deadlocked  by  the  same  argument  used  in  the 
first  half  of  the  proof  of  Theorem  3.1.  The  second  half 

i 

of  the  proof  of  Theorem  3.1  can  not  be  used  here  because 
it  relies  on  Lemma  3.2.  Instead  we  will  use  a  slightly 
more  difficult  argument,  which  could  have  been  used  in 
proving  Theorem  3.  1. 

Let  us  suppose  that  Pi  is  not  deadlocked  in  state  S. 
Then  there  is  a  sequence  of  operations  by  processes 
numbered  jl ,  j2,  ...,  jx  which  leaves  a  state  T  in  which 

Pi  is  not  blocked.  Using  this  sequence  we  will  construct 
'  a  sequence  of  reductions  of  state  S  by  processes  numbered 
kl,  k2 ,  ...,  ky  which  leave  a  state  in  which  Pi  is  not 
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blocked.  For  v  =  1,  2,  3,  ...,  y ,  let  kv  be  the  first 
process  in  the  j  sequence  which  has  not  previously 
appeared  in  the  k  sequence  and  which  is  not  an  isolated 
node  in  state  S.  State  S  can  be  successively  reduced  by 
kl ,  k2,  ...,  ky  because  of  the  fact  that  preceding  the 
reduction  by  process  kv,  every  element  of  the  available 
units  vector  is  at  least  as  large  as  it  was  just  before 
the  corresponding  operation  by  process  kv  during  the  j 
sequence  of  operations.  This  fact  follows  from  the 
observations  that  (a)  a  reduction  by  a  process  sets  the 
available  units  of  resources  produced  by  the  process  to 
OMEGA,  (fc)  a  reduction  by  a  process  decreases  the 
available  units  only  by  requests  existing  in  state  S,  and 
(c)  the  only  processes  which  appear  in  the  j  sequence  but 
not  in  the  k  sequence  are  producers  of  no  resources, 
hence,  each  reduction  leaves  enough  available  units  so  the 
next  reduction  can  take  place,  and  following  the  last 
reduction,  enough  units  are  available  so  Pi  is  not 
blocked.  This  concludes  the  proof. 

It  is  not  true  that  a  consumable  resource  graph  is 
deadlocked  if  and  only  if  it  is  not  completely  reducible. 
Figure  4.4  gives  a  state,  let  us  call  it  S,  in  which  neither 
process  is  deadlocked  (or  even  blocked) ,  and  yet  S  is  not 
completely  reducible.  State  s  can  initially  be  reduced  by 
either  process,  but  then  no  other  reduction  is  possible. 

State  S  is  not  deadlocked,  but  it  has  a  property  quite 
similar  to  deadlock;  namely,  S  has  the  property  that  from  S 
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there  exists  no  sequence  of  operations  which  includes 

operations  by  all  processes  in  the  system-  For  reusable 

resource  systems  it  can  be  shown  that  a  state  has  this 
property  if  and  only  if  it  is  deadlocked.  The  fact  that  a 
state  in  a  consumable  resource  system  can  have  this  property 
and  not  be  deadlocked  shows  that  interactions  due  to 
consumable  resources  are  of  a  more  complex  nature  than 
interactions  due  to  reusable  resources-  This  more  complex 
nature  of  the  interactions  in  a  consumable  resource  system  is 
a  direct  result  of  the  fact  that  acquired  units  of  a 
consumable  resource  can  not  be  released. 

Corollary  3-  1  gives  a  simple  condition  (complete 
reducibility)  which  is  equivalent  to  deadlock  in  reusable 
resource  graphs-  Corollary  4- 1  gives  the  more  complicated 
conditions  for  consumable  resource  graphs. 

Corollary _ 4_-_1  A  consumable  resource  graph  is  not  a 

deadlock  state  if  and  only  if  for  each  process  Pi  there 

i 

exists  a  sequence  of  reductions  of  the  graph  which  leaves 
a  state  in  which  Pi  is  not  blocked. 

This  corollary  is  simply  a  restatement  of  Theorem  4.1  as 
applied  to  all  processes,  and  does  not  suggest  a  simple  method 
of  deadlock  detection. 

Cycles  and  Knots 

Cycles  and  knots  piny  similar  roles  in  reusable  resource 
systems  and  in  consumable  resource  systems.  The  reader  should 
refer  to  Section  3.4  for  a  discussion  of  cycles  and  knots  in 
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reusable  resource  systems.  The  following  theorem  is  analogous 
to  Theorem  3.  2 . 

Theorem_4 2  In  a  consumable  resource  graph, 

(1)  a  cycle  is  a  necessary  condition  for  deadlock,  and 

(2)  if  the  graph  is  expedient,  a  knot  is  a  sufficient 
condition  for  deadlock. 

The  proof  of  Theorem  4.2  is  omitted  because  it  is  quite 
similar  to  the  proof  of  Theorem  3.2. 
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» 


State  S 


State  T 


State  U 


Figure _ 4-_3  Seductions  of  consumable  resource  graphs.  S  is 

reduced  by  PI  to  obtain  T,  and  T  is  reduced  by  P2  to  obtain  U. 
State  S  is  not  a  deadlock  state  because  these  reductions  leave 


all  processes  not  blocked. 
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Figure  4.4  A 
state  and  wi 
can  execute 


PI  P2 


consumable  resource  graph  which  is  not  a  deadlock 
ich  is  not  completely  reducible.  Either  ?1  or  P2 
an  acquisition  operation-  If  either  process 


executes  an  acquisition,  the  other  process  will  be  deadlocked. 
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4.3  A  Deadlock  Detection  Algorithm 

A  reduction  algorithm  for  consumable  resource  graphs 
should  take  advantage  of  several  of  the  techniques  used  for 
fast  reduction  of  reusable  resource  graphs.  These  techniques 
were  discussed  in  Section  3.5  and  include  using  weighted  edges 
and  ordered  queues  of  requests.  These  techniques  allow  the 
algorithm  to  find  (without  searching)  those  processes  which 
are  not  blocked  following  a  reduction.  »e  will  assume  that 
the  deadlock  detection  algorithm  for  consumable  resource 
graphs  uses  weighted  edges  and  ordered  request  queues. 

A  Detection  Algorithm 

Algorithm  4.1  can  be  used  to  detect  deadlock  in 
consumable  resource  systems.  Since  the  order  of  reductions  is 
important,  the  algorithm  attempts  all  possible  orders  of 
reductions.  There  are  n!  different  ways  to  order  n  processes, 
and  since  a  complete  reduction  (for  a  given  ordering  of  the 


processes) 

can 

require  time 

proportional  to  m 

n,  the  maximum 

execution 

time 

of 

Algorithm 

4.  1 

is  proportional  to  n!  m  n. 

(This  is 

only 

a 

motivation 

for 

the  maximum 

execution  time 

formula.  The  formula  is  derived  by  analyzing  the  application 
of  the  algorithm  to  a  worst  case  state,  which  is  a  state  in 
which  exactly  one  process  is  deadlocked.)  This  slow  execution 
time  means  the  algorithm  is  probably  not  of  practical  value 
for  systems  with  more  than  about  5  processes. 

The  reason  the  author  was  not  able  to  develop  a  faster 
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algorithm  than  Algorithm  4. 1  is  because  the  order  of 
reductions  is  important.  There  remains  the  interesting  open 
question:  does  there  exist  a  fast  algorithm  equivalent  to 
Algorithm  4.1? 

Operations  Which  Cause  Deadlock 

For  reusable  resource  systems,  it  was  shown  in  Lemma  3.3 
that  the  only  operation  which  can  change  a  state  which  is  not 
deadlocked  to  a  deadlock  state  is  a  request  for  units  which 
are  not  available.  That  is,  only  requests  which  can  not  be 
granted  can  "cause”  a  deadlock. 

The  behavior  of  consumable  resource  systems  is  more 
complex;  an  acquisition  can  cause  a  deadlock,  and  a  request 
can  cause  a  deadlock  even  when  the  requested  units  are 
available.  The  only  operation  which  can  not  cause  a  deadlock 
is  a  release.  An  acquisition  which  causes  deadlock  will  occur 
if  process  PI  in  Figure  4.4  acquires  the  unit  of  R1  and  the 
unit  of  R2  which  P2  has  requested.  Examples  can  easily  be 
constructed  in  which  a  request  causes  deadlock  even  though  the 
requested  units  are  available. 

This  complex  behavior  of  consumable  resource  systems 
means  that  for  continuous  deadlock  detection.  Algorithm  4.1 
must  be  executed  after  every  request  and  acquire  operation. 
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/*N  counts  the  processes  shown  to  be  not  deadlocked.3*'/ 

1.  N  -  0 ; 

2.  Do  for  each  of  the  n!  orderings  of  the  n  processes  while 

N  is  less  than  n; 

3.  Set  state  T  equal  to  state  S; 

4.  Set  switch  C  to  say  continue  with  this  ordering; 

5.  Do  for  next  process  P  of  ordering  while  C 

says  continue; 

6.  If  process  P  is  not  blocked  in  T  then 

7.  Do ; 

8.  If  P  has  not  yet  been  shown  to  be  not 

deadlocked  then 

9.  Increase  N  by  1 ; 

10-  If  T  can  be  reduced  by  P  then 

11.  Let  state  T  be  state  T  reduced  by  P; 

12.  End; 

13.  Else 

14-  Set  switch  C  to  say  do  not  continue; 

15.  End; 

16.  End; 

17.  Deadlock  =  (N  is  less  than  n)  ; 

Algorithm _ 4^1  Detecting  if  state  S  is  deadlocked  in  a 

consumable  resource  system.  Maximum  execution  time  is 


proportional  to  n!  m  n- 
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4.4  Special  Cases  of  Consumable  Resource  Systems 

In  Section  3.6  we  considered  three  special  cases  of 
reusable  resource  systems.  These  cases  were  (1)  allowing  only 
single  unit  resources,  (2)  allowing  only  single  unit  requests, 
and  (3)  allowing  only  a  single  type  of  resource.  Let  us 
consider  briefly  the  implications  of  these  special  cases  when 
applied  to  consumable  resource  systems. 

Case  _1.  Allowing  only  single  unit  resources  means  the 
total  units  vector  is  all  ones,  i.e.  ,  1 1  -  1 2  =  ...=  tm  = 
1.  Since  there  is  no  total  units  vector  in  consumable 
resource  systems,  this  special  case  does  not  apply 
directly  to  consumable  resource  systems. 

Case  2_.  Allowing  only  single  unit  requests  results  in 
fast  deadlock  detection  algorithms.  Single  unit  requests 
are  special  cases  of  single  resource  requests,  which  will 
be  the  main  topic  of  this  section. 

Case  3^  Allowing  only  a  single  type  of  resource  results 
in  a  highly  restrictive  model  which  is  of  questionable 
usefulness.  By  the  same  token,  deadlock  detection  becomes 
trivial  for  this  special  case;  it  is  easily  shown  that  a 
state  is  deadlocked  if  and  only  if  every  producer  of  the 
resource  is  blocked. 

Single  Resource  Requests 

We  will  investigate  the  simplifications  which  arise  when 
the  system  has  the  following  characteristic: 
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Single  Resource  Requests.  A  process  may  request  units  of 
only  one  resource  at  a  time,  in  a  consumable  resource 
graph  with  weighted  edges  this  means  that  at  most  one 
request  edge  is  directed  from  each  process  node. 

Single  resource  requests  have  the  same  disadvantages  of  single 
unit  requests;  namely,  they  may  decrease  resource  utilization, 
and  they  may  increase  the  frequency  of  deadlock.  These 
disadvantages  are  not  as  severe  with  single  resource  requests 
as  they  are  with  single  unit  requests  simply  because  requests 
may  be  for  more  than  one  unit  (of  one  resource)  . 

Allowing  only  single  resource  requests  results  in  two 
important  simplifications:  (1)  the  order  of  reductions  of  an 
expedient  state  becomes  unimportant,  and  (2)  deadlocks  and 
knots  become  equivalent  in  expedient  states.  Lemma  4.1  states 
this  first  advantage. 

Lemma  4.  1  Any  seguence  of  reductions  of  an  expedient 
consumable  resource  graph  with  single  resource  requests 
leads  to  a  unique  consumable  resource  graph  which  can  not 
be  reduced. 

Proof  First  we  will  show  that  reductions  of  an  expedient 
consumable  resource  graph  S  can  never  decrease  the 
available  units.  If  a  reduction  increases  an  element  rj 
of  the  available  units  vector,  then  it  necessarily  sets  rj 
to  OMEGA.  Thus,  if  rj  is  still  finite  (not  OMEG&)  after  a 
number  of  reductions,  then  the  value  of  rj  can  not  have 
increased  since  the  original  graph  S.  If  a  process  node 
Pi  which  can  be  reduced  has  a  request  edge  directed  from 
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Pi  to  Rj,  then  necessarily  rj  has  been  set  to  OMEGA  by 
some  previous  reduction;  otherwise,  the  original  graph  S 
could  not  have  been  expedient  because  the  request  by  Pi 
was  for  units  available  in  S.  Hence,  a  reduction  can 
"decrease"  rj  only  when  rj  has  been  set  to  OMEGA,  and  this 
decrease  leaves  the  value  of  rj  unchanged. 

Since  reductions  can  not  decrease  the  available 
units,  any  reduction  which  is  possible  before  another 
reduction  will  also  be  possible  after  another  reduction. 
Hence,  any  sequence  of  reductions  leads  to  a  unique  state 
which  can  not  be  reduced. 

Using  Lemma  4.1,  we  have  a  result  similar  to  Corollary  3.1: 

Lemma _ 4_.2  An  expedient  consumable  resource  graph  with 

single  resource  requests  is  not  a  deadlock  state  if  and 
only  if  it  is  completely  reducible. 

Proof  fhe  proof  is  similar  to  the  proof  of  Corollary  3.1. 
Single  unit  requests  in  reusable  resource  systems  and 
single  resource  requests  in  consumable  resource  systems  make 
similar  simplifications  in  that  in  both  cases,  deadlocks  and 
knots  become  equivalent. 

Theorem _ 4.3  An  expedient  consumable  resource  graph  with 

single  resource  requests  is  a  deadlock  state  if  and  only 
if  it  contains  a  knot. 

Proof  Theorem  4.2(2)  states  that  a  knot  is  a  sufficient 
condition  for  deadlock  in  an  expedient  state.  Thus  we 
need  to  show  that  a  knot  is  a  necessary  condition  for 
deadlock  when  the  expedient  state  has  only  single  resource 
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requests.  The  proof  that  a  knot  is  a  necessary  condition 
for  deadlock  will  be  omitted  because  it  is  analogous  to 
the  proof  of  Theorem  3.4. 

Theorem  4.3  is  probably  the  most  useful  result  about 
consumable  resource  systems  given  here;  it  means  that  there  is 
an  important  subcase  of  consumable  resource  systems  for  which 
deadlock  detection  is  fast.  If  only  single  resource  requests 
are  allowed  and  if  all  possible  requests  are  granted  (i.e., 
the  state  is  made  expedient) ,  then  deadlock  detection  can  be 
accomplished  by  testing  for  knots.  Thus,  Algorithm  3.5,  which 
detects  for  knots,  can  be  used  for  fast  deadlock  detection. 

If  continuous  deadlock  detection  is  required,  then  the 
state  must  be  tested  for  deadlock  after  each  operation  which 
can  cause  deadlock,  i.e.,  after  each  operation  which  can 
change  a  state  which  is  not  deadlocked  to  a  state  which  is 
deadlocked.  We  will  define  an  obvious  restriction  on  the 
system  *  s  behavior  which  will  limit  the  number  of  operations 
which  can  cause  deadlock. 

A  system  is  expedient  if  release  and  request  operations 
are  defined  (possible)  only  when  no  acquisition  operation 
is  defined  (possible). 

Intuitively,  a  system  is  expedient  if  no  request  is  allowed  to 
remain  ungranted  when  the  requested  units  are  available. 

Lemma  4.3  In  an  expedient  consumable  resource  system  with 
single  resource  requests,  suppose  S  is  an  expedient  state, 
T  is  not  a  deadlock  state,  S  -*->  T,  and  an  operation  by 
process  Pi  changes  state  T  to  state  U.  Then  U  is  a 
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deadlock  state  if  and  only  if  the  operation  by  Pi  is  a 
request  and  Pi  is  deadlocked  in  U. 

Proof  The  proof  is  a  somewhat  tedious  case  by  case 
analysis  of  all  possible  operations  by  Pi. 

Case  1.  We  will  show  that  if  the  operation  is  either 
a  release  or  one  of  the  acquisitions  following  a  release, 
then  the  operation  can  not  change  a  state  which  is  not 
deadlocked  to  a  deadlock  state.  Suppose  a  release 
operation  by  process  Pi  changes  the  state  from  T  to  U.  T 
and  0  must  be  identical  except  that  there  are  more 
available  units  in  U.  Since  T  is  completely  reducible,  so 
is  U;  hence,  a  release  can  not  result  in  a  deadlock  state. 
The  release  by  Pi  may  be  immediately  followed  by  one  or 
more  acquisitions;  let  V  be  the  state  following  all 
possible  acquisit ions.  Since  T  is  expedient  (otherwise 
the  release  would  not  have  been  possible) ,  each 
acquisition  must  be  for  a  resource  just  released.  Since 
Pi  is  a  producer  of  each  resource  acquired,  and  Pi  has  no 
request  edges  in  V,  V  can  be  reduced  by  Pi.  Similarly,  T 
can  be  reduced  by  Pi.  Seducing  V  and  T  by  Pi  yields 
states  which  are  identical  except  that  in  the  reduced 
version  of  V  there  are  fewer  reguests  for  resources. 
Since  T  is  completely  reducible,  then  so  is  V,  and  V  is 
not  a  deadlock  state.  Thus,  we  have  shown  that 
acquisition  operations  following  a  release  can  not  change 
a  state  which  is  not  deadlocked  to  a  state  which  is 


deadlocked. 
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Case  2.  We  will  show  that  if  the  operation  is  either 
a  request  for  units  which  are  available  or  an  acquisition 
following  such  a  request,  then  the  operation  can  not 
change  a  state  which  is  not  deadlocked  to  a  deadlock 
state.  Suppose  a  request  operation  by  Pi  is  for  available 
units  of  resource  Rj  and  changes  the  state  from  T  to  D. 
Then  the  request  must  be  immediately  followed  by  an 
acquisition;  let  V  be  the  state  resulting  from  the 
acquisition.  States  T  and  V  will  be  the  same  except  that 
there  will  be  less  available  units  of  Rj  in  V.  Since  T  is 
expedient  (otherwise  the  request  would  not  have  been 
possible)  and  T  is  completely  reducible,  any  reduction  of 
T  by  a  process  with  a  request  for  Rj  must  be  preceded  by  a 


reduction 

which 

sets 

rj  to  OMEGA. 

Since  T  and  V  are 

identical 

except 

for 

rj,  the  same 

reductions  can  be 

applied  to  T  and  V;  thus  V  like  T,  is  completely 
reducible.  Hence,  V  is  not  deadlocked  and  neither  is  U. 

t 

We  have  shown  that  neither  the  request  nor  the  following 
acquisition  resulted  in  a  deadlock  state. 

Case  3.  It  remains  only  to  show  that  a  request  for 
units  which  are  not  available  will  result  in  a  deadlock 
state  if  and  only  if  the  requesting  process  becomes 
deadlocked.  Suppose  the  request  is  by  Pi  and  changes  the 
state  from  T  to  U.  If  Pi  is  deadlocked  in  U  then  by 
definition,  D  is  a  deadlock  state.  If  Pi  is  not 
deadlocked  in  U,  then  state  U  can  be  reduced  to  a  state  V 
in  which  Pi  is  not  blocked.  But  now  the  same  sequence  of 


SECTION  4.4  144 


reductions  which  completely  reduces  T  can  completely 
reduce  V  (we  delete  from  the  sequence  those  processes 
whose  reductions  changed  D  to  V)  •  Hence,  if  Pi  is  not 
deadlocked  following  the  request  then  the  request  did  not 
result  in  a  deadlock  state.  This  concludes  the  proof. 

Lemma  4.3  means  that  continuous  deadlock  detection  can  be 
accomplished  with  very  little  overhead.  All  that  is  required 
is  a  test  for  deadlock  following  each  request  which  can  not  be 
immediately  granted.  If  such  a  request  has  caused  a  deadlock, 
then  it  must  be  that  the  requesting  process  has  become 
deadlocked.  It  is  easily  shown  that  the  requesting  process 
will  be  deadlocked  if  and  only  if  the  process's  node  is  in  a 
knot,  and  thus.  Algorithm  3.6  gives  a  fast  method  of  detecting 
deadlock. 

In  summary,  consumable  resource  systems  can  be  made  to 
have  simple  deadlock  properties  (deadlocks  and  knots  become 
equivalent)  and  fast  deadlock  detection  algorithms  (Algorithms 
.3.5  and  3-6)  by  allowing  only  single  resource  requests  and  by 
making  the  system  expedient. 
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4.5  Systems  Which  Are  Safe 

In  this  section  we  introduce  process  "claims"  which 
determine  which  processes  can  request  which  resources.  Given 
process  claims,  we  develop  necessary  and  sufficient  conditions 
for  a  system  to  be  safe.  (The  reader  may  wish  to  review  the 
definitions  of  "safe  state"  and  "safe  system"  given  in  Section 
2.2.) 

In  consumable  resource  systems,  as  defined  in  Section 
4.1,  no  state  is  safe,  i.e. ,  for  any  state  S,  S  -*->  T  where  T 
is  a  deadlock  state.  This  is  obvious  because  all  processes 
which  are  not  blocked  can  request  more  units  than  are 
available,  thereby  deadlocking  all  processes. 

The  definition  of  consumable  resource  systems  included 
the  specification  of  exactly  which  processes  release  which 
resources.  That  is,  we  know  which  processes  "produce"  which 
resources.  An  obvious  extension  of  this  definition  would 
include  the  specification  of  exactly  which  processes  request 
which  resources.  That  is,  we  would  know  which  processes 
"consume"  which  resources.  We  will  make  this  extension  by 
defining  the  "consumers"  of  each  resource. 

We  will  associate  with  each  resource  Rj  a  nonempty  subset 
of  the  processes  which  will  be  called  the  consumers  of  Rj.  We 
will  assume  that  every  process  is  a  producer  or  a  consumer  (or 
both)  of  at  least  one  resource.  We  define  a  claim  limited 
consumable  resource  system  as  a  consumable  resource  system 


from  which  has  been  eliminated  each  request  by  process  Pi,  1  < 
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i  ^  n,  for  resource  Rj,  1  <  j  <  n,  such  that  Pi  is  not  one  of 
the  consumers  of  Rj.  In  this  chapter  there  are  only 
consumable  resources  {no  reusable  resources) ,  and  so  claim 
limited  consumable  resources  systems  will  be  called  simply 
claim  limited  systems. 

We  will  now  single  out  a  special  state,  called  a  claim 
limited  consumable  resource  graph,  which  will  be  used  to 
determine  if  a  claim  limited  system  is  safe;  we  shall  show  (in 
Theorem  4.4)  that  safeness  is  equivalent  to  the  complete 
reducibility  of  this  special  state. 

We  define  the  claim  limited  consumable  resource  graph  for 
a  given  claim  limited  system  as  the  consumable  resource 
graph  in  the  system  with  zero  available  units  (rl  -  r2  - 
...  ■=  rm  =  0)  and  with  a  reguest  edge  directed  from 
process  node  Pi  to  resource  node  Rj  if  and  only  if  Pi  is 
one  of  the  consumers  of  Rj. 

In  this  chapter  a  claim  limited  consumable  resource  graph  will 
be  cal led ,  simply,  a  claim  limited  graph . 

Figure  4.5  gives  an  example  of  a  claim  limited  graph.  In 
the  figure,  resource  Rl  has  two  producers,  PI  and  P2,  and  one 
consumer,  P2.  Resource  R2  has  one  producer,  PI,  and  one 
consumer,  P2.  The  processes,  resources,  producers,  and 
consumers  of  the  system  are  uniquely  determined  by  its  claim 
limited  graph,  and  thus,  a  claim  limited  system  is  completely 
characterized  by  its  claim  limited  graph. 

Notice  that  in  the  state  which  is  the  claim  limited 
graph,  if  every  process  consumes  at  least  one  resource,  then 
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the  state  will  be  totally  deadlocked,  i.e.,  all  processes  will 
be  blocked.  Stating  this  another  way,  if  the  claim  limited 
graph  is  not  a  deadlock  state  then  at  least  one  process  must 
be  a  consumer  of  no  resources.  (We  will  use  this  fact  in  the 
proof  of  Theorem  4.4.) 

Lemma  .4-4  Any  sequence  of  reductions  of  a  claim  limited 
consumable  resource  graph  leads  to  a  unique  graph  which 
can  not  be  reduced. 

Proof  The  proof  follows  from  the  observation  that 
reductions  of  a  claim  limited  graph  can  only  increase 
(never  decrease)  the  available  units.  The  proof  is  not 
given  because  it  is  similar  to  the  proof  of  Lemma  4. 1. 

From  lemma  4.4  it  follows  easily  that  a  claim  limited 
graph  is  not  a  deadlock  state  if  and  only  if  it  is  completely 
reducible.  Since  Lemma  4.4  implies  that  the  order  of 
reductions  is  not  important,  a  fast  algorithm,  similar  to 
Algorithms  3.3  and  3.5,  can  be  used  to  determine  if  a  claim 

i 

limited  graph  is  completely  reducible. 

Theorem  4^4  A  claim  limited  consumable  resource  system  is 
safe  if  and  only  if  its  claim  limited  consumable  resource 
graph  is  completely  reducible. 

Proof  Let  the  claim  limited  graph  be  called  V.  The 
theorem  will  be  proved  by  (1)  assuming  V  is  not  completely 
reducible  (and  thus  V  is  a  deadlock  state)  and  showing 
that  for  any  (supposedly)  safe  state  S,  S  -*->  V,  and  (2) 
assuming  V  is  completely  reducible  and  showing  that  any 
state  S  is  also  completely  reducible. 
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(1)  Assume  V  is  not  completely  reducible,  i.e., 
assume  V  is  a  deadlock  state.  Assume  there  is  a  safe 
state  S.  We  will  derive  the  contradiction  that  S  -*->  V 
by  showing: 

(a)  S  -*->  T  where  T  is  a  state  with  no  request  edges, 

(b)  T  -*->  0  where  0  is  a  state  with  no  request  edges 

and  zero  available  units,  and 

(c)  U  — *->  V  where  V  is  the  claim  limited  graph. 

Since  S  is  a  safe  state,  there  exists  a  sequence  of 
operations  by  processes  numbered  jl,  j2,  ...,  jx  which 
includes  all  processes.  From  this  sequence,  we  can 
construct  a  sequence  of  reductions  kl,  k2,  ...,  ky  which 
deletes  all  edges  in  S.  The  construction  is  omitted 
because  it  is  the  same  as  the  construction  described  in 
the  proof  of  Theorem  4.1.  The  construction  shows  that  S 
is  completely  reducible,  and  it  follows  easily  that  S  -*-> 
T.  From  state  T,  consumers  of  each  resource  can  request 
and  acquire  any  available  units;  thus,  T  -♦->  U.  From 
state  U  each  process  can  request  one  unit  of  each  resource 
it  claims;  thus,  U  — ♦— >  V.  Therefore,  S  -*->  V.  Since 
this  is  a  contradiction,  it  must  be  that  if  V  is  not 
completely  reducible,  no  state  is  safe,  and  the  system  is 
not  safe. 

(2)  Assume  V  is  completely  reducible.  We  will  show 
that  any  state  S  can  be  completely  reduced  by  the  same 
sequence  which  completely  reduces  V.  (We  delete  from  the 
sequence  which  completely  reduces  V  those  processes  which 
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have  isolated  nodes  in  S.)  Let  the  first  process  in  the 
sequence  which  completely  reduces  V  be  called  PI.  PI  can 
not  be  blocked  in  S  because  PI  is  a  consumer  of  no 
resources.  (If  PI  were  a  consumer  of  one  or  more 
resources,  then  V  could  not  be  reduced  by  Pi.)  Let  S  be 
reduced  by  PI  to  state  SI.  (If  S  can  not  be  reduced  by  Pi 
because  PI  is  an  isolated  node  in  S,  let  SI  =  S.)  Let  the 
second  process  in  the  sequence  which  completely  reduces  V 
be  called  P2.  P2  can  not  be  blocked  in  Si  because  P2  is  a 
consumer  only  of  resources  produced  by  Pi.  (If  P2  were  a 
consumer  of  resources  not  produced  by  PI,  then  V  could  not 
be  reduced  by  PI  and  then  by  P2.)  Let  S  be  reduced  by  P2 
to  state  S2.  (If  P2  is  an  isolated  node  in  S,  let  S2  = 
Si.)  Continuing  in  this  manner,  S  can  be  successively 
reduced  to  Si,  S2,  S3,  ...,  Sn,  where  all  edges  have  been 
deleted  in  Sn.  Hence,  any  arbitrary  state  S  is  not  a 
deadlock  state,  and  all  states  in  the  system  are  safe. 

The  claim  limited  graph  in  Figure  4.5  can  be  reduced  by 
PI  and  then  by  P2.  Since  these  reductions  delete  all  edges  in 
the  graph,  the  graph  is  completely  reducible.  Hence,  every 
state  in  the  system  is  safe. 

Combining  Theorem  4.4  with  Theorem  4.2(1)  we  have  the 
corollary:  if  a  claim  limited  graph  does  not  contain  a  cycle 
then  the  system  is  safe.  In  his  thesis,  Habermann 
[pg. 46, 1967]  uses  the  term  "hierarchical"  to  describe  a 
directed  graph  which  contains  no  cycles.  We  can  restate  our 
corollary  as  follows: 
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If  the  claim  limited  consumable  resource  graph  is 
heirarchical,  then  the  claim  limited  consumable  resource 
system  is  safe. 

We  state  this  corollary  to  establish  a  relationship  between 
Theorem  4.4  and  analogous  theorems  obtained  by  Habermann 
[ pp. 46-49, 1967  ].  Habermann* s  results  apply  to  a  model  of 
operating  systems  which  is  substantially  different  from 
consumable  resource  systems.  His  theorems  state  that  in  a 
system  with  "hierarchical  structure"  the  processes  "cooperate 
harmoniously",  i-e.,  all  processes  finish- 


SECTION  4.5  151 


HI 


Figure _ 4^5  Example  of  a  claim  limited  consumable  resource 

graph.  Since  this  graph  is  completely  reducible,  all  states 


in  the  system  are  safe. 
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4.6  Other  Models  with  Explicit  Interactions 

We  have  investigated  consumable  resource  systems  as  a 
model  of  systems  with  explicit  interactions  because  they 
include  the  features  of  the  well  known  mechanisms  for  explicit 
interactions  among  processes  in  computer  systems.  These  well 
known  mechanisms  include  Dijkstra's  semaphores  [  1965a], 
Lampson’s  wakeup  switches  [1968],  and  OS/360  events  [IBM 
1968a]. 

Semaphores 

A  semaphore  [Dijkstra  1965a]  is  a  counter  (a  word  in 
storage)  with  a  nonnegative  value.  We  can  consider  that  a 
semaphore  is  a  resource  where  the  number  of  available  units  of 
the  resource  is  the  value  of  the  semaphore.  Dijkstra  allows 
two  operations  on  semaphores:  ”Pn  operations  and  **V” 
operations.  Each  of  these  operations  must  specify  a  semaphore 
to  which  it  applies- 

% 

A  P  operation  is  exactly  like  a  single  unit  request 

(followed  by  an  acquisition).  A  P  operation  causes  the 
executing  process  to  be  blocked  until  the  value  of  the 
semaphore  is  strictly  positive.  Once  the  value  becomes 
strictly  positive,  the  value  is  decremented  by  one  and  the 
process  is  no  longer  blocked. 

A  V  operation  is  exactly  like  a  single  unit  release, 

i.e.,  it  increments  the  value  of  the  semaphore  by  one  without 


SECTION  4.6  153 


blocking  the  executing  process. 

In  his  article  about  the  THE  system,  Dijkstra  [1968]  says 
that  semaphores  are  used  for  two  main  purposes:  (1)  to 
implement  critical  sections,  and  (2)  as  ’’private  semaphores”. 
As  was  stated  in  Section  3.1,  a  critical  section  behaves 
exactly  like  a  reusable  resource,  and  thus  a  semaphore  used  to 
implement  a  critical  section  can  be  considered  to  be  a 
reusable  resource. 

A  private  semaphore  is  a  semaphore  which  is  associated 
with  a  particular  process.  Suppose  private  semaphore  Si  is 
associated  with  process  Pi.  When  process  Pi  reaches  a  point 
where  it  requires  a  signal  or  message  from  another  process, 
then  Pi  executes  a  P  operation  on  semaphore  Si.  Presumably, 
the  other  process  will  execute  (or  has  executed)  a  V  operation 
on  Si,  so  Pi  will  not  be  blocked  forever.  The  private 
semaphore  Si  can  be  considered  to  be  a  consumable  resource 
whose  only  consumer  is  process  Pi. 

When  all  the  semaphores  in  a  system  behave  like 
consumable  resources,  the  lemmas  and  theorems  given  in  this 
chapter  can  be  used  in  detecting  and  preventing  deadlock. 
Given  that  the  system  state  is  expedient,  i.e. ,  given  that  all 
possible  P  operations  have  completed.  Theorem  4.3  states  that 
a  knot  is  a  necessary  and  sufficient  condition  for  deadlock. 
Theorem  4.4  can  be  used  to  determine  if  the  system  is  safe. 

Of  course.  Theorem  4.3  can  be  applied  only  when  one  knows 
the  producers  of  each  resource,  i.e.,  when  one  knows  which 
processes  execute  V  operations  on  which  semaphores. 
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Similarly,  Theorem  4.4  can  be  applied  only  when  one  knows  the 

producers  and  consumers  of  each  resource,  i-e-,  when  one  knows 
\ 

which  processes  execute  P  and  V  operations  on  which 
semaphores. 

Wakeup  Switches 

Lampson  [1968]  has  described  a  simple  method  of  process 
synchronization  which  uses  "wakeup  switches”.  (We  have 
shortened  his  original  term  which  was  "wakeup  waiting 
switches”.)  There  is  a  wakeup  switch  associated  with  each 
process  in  the  system  and  wakeup  switches  serve  much  the  same 
purpose  as  private  semaphores.  A  wakeup  switch  is  quite 
similar  to  a  consumable  resource  whose  number  of  available 
units  is  0  or  1  according  to  whether  the  value  of  the  wakeup 
switch  is  0  or  1. 

Lampson  allows  two  operations  on  wakeup  switches:  Block 
and  Wakeup.  (Actually,  Lampson  also  allows  operations  called 
"Suspend”,  "Release",  and  "Test  and  Set".  Although  the 
following  discussion  will  ignore  these  operations,  it  could  be 
expanded  to  include  them.) 

A  block  operation  must  specify  a  process  number.  First, 
let  us  consider  the  case  in  which  the  Block  operation 
specifies  the  invoking  process.  Let  the  wakeup  switch 
associated  with  each  process  Pi  be  called  Wi.  A  block 
operation  executed  by  process  Pi  specifying  process  number  i 
is  exactly  like  a  single  unit  request  (followed  by  an 
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acquisition)  for  resource  Si.  The  Block  operation  causes  Pi 
to  be  blocked  until  the  value  of  Wi  is  strictly  positive 
(which  is  until  Hi  =  1).  Once  Hi  is  1,  then  Hi  is  set  to  0, 
and  Pi  is  no  longer  blocked.  Now  let  us  consider  the  case  in 
which  the  Block  operation  specifies  a  process  number  other 
than  the  number  of  the  invoking  process.  A  Block  operation 
executed  by  process  Pi  specifying  process  number  j  (j  #  i)  is 
equivalent  to  forcing  process  Pj  to  execute  a  single  unit 
request  (followed  by  an  acquisition)  for  resource  Wj.  Process 
Pi  is  not  blocked  by  the  operation,  but  process  Pj  becomes 
blocked  and  remains  blocked  until  the  value  of  Hj  is  strictly 
positive  (which  is  until  Hj  -  1).  Once  Wj  is  1r  then  Wj  is 
set  to  0,  and  Pj  is  no  longer  blocked.  The  fact  that  a 
process  can  only  be  blocked  waiting  for  its  own  wakeup  switch 
means  that  the  consumers  of  the  system  are  known;  that  is,  for 
all  i,  the  only  consumer  of  Wi  is  Pi. 

A  Wakeup  operation  may  refer  to  any  wakeup  switch  Wj,  and 
is  similar  to  a  single  unit  release  for  resource  Wj.  If  Wj  = 
0,  then  a  Wakeup  operation  applied  to  Wj  sets  the  value  of  Wj 
to  1;  this  is  equivalent  to  a  single  unit  release  for  resource 
Wj.  If  wj  =  1,  then  a  Wakeup  operation  applied  to  Wj  leaves 
the  value  of  Wj  as  1;  in  this  case,  a  single  unit  release  is 

not  equivalent  to  a  Wakeup  operation. 

Although  Wakeup  switches  are  different  from  consumable 
resources  in  that  the  maximum  ''available  units"  of  a  wakeup 
switch  is  1,  the  logic  of  process  interactions  is  essentially 
the  same  for  consumable  resources  and  wakeup  switches. 
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Without  pursuing  the  matter  in  detail  we  assert  that  theorems 
similar  to  Theorems  4.3  and  4.4  can  be  proved  for  systems 
using  wakeup  switches  for  explicit  interactions.  Of  course, 
in  order  to  apply  these,  one  will  need  to  know  the  producers 
of  each  resource,  i.e.,  one  must  know  which  processes  execute 
Wakeup  operations  for  which  wakeup  switches. 

Events 

A  method  of  process  synchronization  using  switches  called 
"events”  has  been  proposed  by  Dahm  et  al  [1967].  A  method 
similar  to  theirs  is  implemented  in  the  IBM  OS/360  system  [IBM 
1968a].  In  OS/360  three  operations  can  be  applied  to  events: 
Waits.  A  Wait  operation  must  specify  a  particular  event. 
A  process  executing  a  Wait  operation  is  blocked  until  the 
value  of  the  event  becomes  1.  Once  the  value  of  the  event 
becomes  1,  the  process  is  no  longer  blocked.  The  Wait 
operation  leaves  the  value  of  the  event  as  1.  (Actually, 
in  OS/360  the  Wait  operation  can  specify  multiple  events 
together  with  a  "wait  count”  giving  the  number  of  events 
required  to  be  1;  the  process  executing  the  Wait  operation 
is  blocked  until  the  given  number  of  events  become  1. 
Although  we  will  assume  a  process  can  only  wait  for  one 
event  at  a  time,  the  following  discussion  can  be  expanded 
to  the  more  general  case.) 

Posts.  A  Post  operation  specifies  a  particular  event  and 
sets  that  event  to  1. 
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£  112.1!  ffLi  A  Turnoff  operation  specifies  a  particular 
event  and  sets  that  event  to  0.  (The  Turnoff  operation 
has  no  special  name  in  OS/360,) 

None  of  these  operations  correspond  exactly  to  the  operations 
in  a  consumable  resource  system.  However,  Waits  and  Turnoffs 
are  similar  in  function  to  requests  and  acquisitions  of  single 
units.  Posts  are  similar  in  function  to  releases  of  single 
units. 

Theorems  similar  to  Theorems  4.3  and  4.4  can  be  proved 
for  systems  using  event  switches  for  explicit  interactions. 
Of  course,  in  order  to  apply  Theorem  4.3,  one  must  Know  the 
producers  of  each  resource,  i.e. ,  one  must  know  which 
processes  execute  Post  operations  for  which  events.  In  order 
to  apply  Theorem  4.4,  one  must  also  know  the  consumers  of  each 
resource,  i.e.,  one  must  know  which  processes  can  execute  Wait 
operations  for  which  events. 

As  events  are  presently  implemented  in  OS/360,  the 
operating  system  does  not  have  any  information  about  which 
processes  Post  which  events;  without  this  information,  the 
operating  system  can  not  detect  deadlock  except  in  the 
catastrophic  situation  where  every  process  is  deadlocked. 

A  Wait  operation  is  different  from  either  a  request 
operation  (followed  by  an  acquisition)  or  a  Block  operation  in 
that  a  Wait  operation  does  not  turn  off  a  switch  (or  decrement 
the  available  units) •  Hence,  for  state  graphs  in  systems 
using  events,  the  order  of  reductions  will  not  be  important, 

reducibility  will  be  equivalent  to 


and  complete 


"not 
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deadlock".  One  can  sho*  that  the  order  of  reductions  for 
these  graphs  will  not  be  important  even  if  the  processes  are 
allowed  to  wait  for  multiple  events. 

Our  purpose  in  discussing  semaphores,  wakeup  switches, 
and  events  has  been  to  demonstrate  that  the  results  obtained 
for  consumable  resource  systems,  and  the  methods  used  to 
derive  these  results  are  of  general  applicability.  In  doing 
so.  we  hope  that  we  have  shown  that  consumable  resource 
systems  are  a  good  general  model  for  systems  of  processes  with 
explicit  interactions. 

In  this  chapter  we  have  confined  our  attention  to  systems 
in  which  the  only  interactions  among  processes  are  the  result 
of  passing  messages  {consumable  resources) .  It  was  shown  that 
deadlock  is  equivalent  to  the  "non-reducibility"  of  a  directed 
graph  representing  the  system  state.  Several  deadlock 
detection  algorithms  were  developed.  A  simple  test  to 
determine  if  a  system  is  safe  from  deadlock  was  presented. 
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CHAPTER  5.  A  GENERAL  MODEL  AND  IMPLEMENTATIONS 

In  Chapter  3  we  investigated  implicit  interactions  among 
processes  caused  by  reusable  resources  and  in  Chapter  4  we 
investigated  explicit  interactions  among  processes  caused  by 
consumable  resources.  In  this  chapter  we  investigate  systems 
in  which  interactions  among  processes  can  be  caused  by  both 
reusable  and  consumable  resources.  It  will  be  shown  that  most 
of  the  results  of  Chapters  3  and  4  can  be  extended  to  systems 
having  both  types  of  resources.  In  this  chapter  we  also 
discuss  and  give  examples  of  implementations  of  the  request 
and  release  operations. 

5-1  Re  usable  and  Consumable  Resources  in  One  Model 

In  this  section  we  give  a  formal  model  of  systems  having 
both  reusable  and  consumable  resources  and  extend  many  of  the 
results  of  the  two  previous  chapters  to  apply  to  this  model. 

i 

General  Resource  Systems 

We  will  call  a  system  which  can  have  both  types  of 
resources  a  “general  resource  system”.  Each  state  in  such  a 
system  will  be  called  a  "general  resource  graph”.  General 
resource  graphs  are  like  reusable  resource  graphs  and 
consumable  resource  graphs  except  that  the  resource  nodes  are 
divided  into  two  subsets:  the  reusable  resource  nodes  and  the 


consumable  resource  nodes- 
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In  a  general  resource  graph,  edges  directed  from 
consumable  resource  nodes  are  called  producer  edges.  Edges 
directed  from  reusable  resource  nodes  are  called  assignment 
edges.  Edges  directed  from  process  nodes  are  called  reguest 
edges.  He  define: 

A  general  resource  system  is  completely  characterized  by 

(1)  a  nonempty  set  of  processes  PI= {P 1 ,P2,. , . Pn} , 

(2)  a  nonempty  set  of  resources  RHC5= {R 1 , R2, . - . Rm} , 

(3)  a  partition  or  RHO  into  two  disjoint  subsets,  a  set  of 
reusable  resources  and  a  set  of  consumable  resources, 

(4)  for  each  reusable  resource  Rj,  a  strictly  positive 
integer  tj,  called  the  total  units  of  Rj,  and 

(5)  for  each  consumable  resource  Rj,  a  nonempty  subset  of 
the  processes  which  will  be  called  the  producers  of  Rj. 

The  set  of  states  SIGMA  of  a  general  resource  system  is  the 
set  of  all  general  resource  graphs  for  the  system.  He  define: 
A  general  resource  graph  is  any  bipartite  directed  graph 
whose  disjoint  sets  of  nodes  are  PI=  (P 1 , P2, , . . , Pn}  and 
RH0=  {R 1 , R 2 , , • • , Rm}  ,  together  with  an  available  units 
vector  {r 1,r2,,.,rm)  such  that 
(1)  for  a  given  reusable  resource  node  Rj, 

(a)  the  number  of  assignment  edges  directed  from  Rj 
does  not  exceed  tj, 

(b)  rj  is  equal  to  tj  minus  the  number  of  assignment 
edges  directed  from  Rj, 

(c)  for  a  given  process  node  Pi,  the  number  of  request 
edges  (Pi,Rj)  plus  the  number  of  assignment  edges 


SECTION  5.1  161 


(Rj,Pi)  does  not  exceed  tj, 

(2)  for  a  given  consumable  resource  node  Rj, 

(a)  there  is  a  producer  edge  directed  from  Rj  to 
process  node  Pi  if  and  only  if  Pi  is  one  of  the 
producers  of  Rj, 

(b)  rj  is  any  nonnegative  integer. 

See  Figure  5.  1  for  an  example  of  a  general  resource  graph. 

The  operations  in  a  general  resource  system  are  requests, 
acquisitions,  and  releases.  Since  the  definitions  of  requests 
and  acquisitions  are  identical  to  those  given  in  Chapters  3 
and  4,  they  will  not  be  repeated  here.  For  system  states  S 
and  T,  we  define: 

Releases.  In  state  S  if  no  request  edges  are  directed 
from  node  Pi,  and  some  edges  (assignment  or  producer 
edges)  are  directed  to  Pi,  then 

S  -i->  T 

where  S  and  T  are  identical  except  that  at  least  one 
resource  Rj  having  one  or  more  edges  (assignment  or 
producer  edges)  directed  from  Rj  to  Pi  has  its  available 
units  (rj)  increased;  if  Rj  is  a  reusable  resource  then 
there  are  deleted  a  number  of  assignment  edges  (Rj,Pi) 
equal  to  the  number  by  which  rj  is  increased. 

From  the  definitions  of  "request",  "acquisition",  and 
"release"  it  follows  that  a  process  Pi  is  blocked  if  and  only 
if  there  is  a  resource  node  Rj  such  that  the  number  of  request 
edges  directed  from  Fi  to  Rj  exceeds  rj  (the  available  units 

of  R  j)  - 
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Graph  Reductions  and  Deadlock 

We  extend  the  definition  of  deduction”  to  apply  to 
general  resource  systems: 

A  general  resource  graph  can  be  reduced  by  any  process 
node  which  is  not  an  isolated  node  and  which  is  not 
blocked.  The  reduction  by  Pi 

(1)  for  each  reusable  resource  node  Rj,  deletes  all  edges 
(Pi,8j)  and  (Rj,Pi)  (for  each  assignment  edge  (Rj,Pi) 
deleted,  r  j  is  increased  by  one) ,  and 

(2)  for  each  consumable  resource  node  Rj, 

(a)  decrements  rj  by  the  number  of  request  edges 
directed  from  Pi  to  Rj, 

(b)  sets  rj  to  OMEGA  if  Pi  is  a  producer  of  Rj,  and 

(c)  deletes  all  edges  (Pi,Rj)  and  (Rj,Pi). 

In  Chapters  3  and  4  we  defined  “expedient  states”  and 
“single  unit  requests”.  Osing  these  definitions,  we  state  the 
following  results  for  general  resource  systems. 

Theorem  5.  1  Process  Pi  is  not  deadlocked  if  and  only  if  a 
sequence  of  reductions  leaves  a  state  in  which  Pi  is  not 
blocked. 

Theorem  5.2  In  a  general  resource  graph, 

(1)  a  cycle  is  a  necessary  condition  for  deadlock,  and 
<2)  if  the  graph  is  expedient,  then  a  knot  is  a  sufficient 
condition  for  deadlock. 

Theorem _ 5.3  An  expedient  general  resource  graph  with 

single  unit  requests  is  a  deadlock  state  if  and  only  if  it 
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contains  a  knot. 

The  proofs  of  these  theorems  are  similar  to  proofs  in  Chapters 
3  and  4  and  will  not  be  given  here.  Theorem  5.3  can  easily  be 
generalized  to  allow  single  resource  requests  for  consumable 
resources. 

In  Figure  5. 1  the  available  units  vector  of  the  general 
resource  graph  is  (1,2,0).  The  graph  can  be  reduced  by  PI 
leaving  available  units  (2,2,2),  and  then  reduced  by  P2 
leaving  available  units  (2, OMEGA, 2).  After  the  two 
reductions,  no  process  is  blocked;  thus,  the  graph  was  not  a 
deadlock  state. 

Theorems  5.1  and  5.2  provide  a  brief  summary  of  the 
results  we  have  developed  for  reusable  resource  systems, 
consumable  resource  systems,  and  general  resource  systems. 
For  all  these  systems,  (a)  deadlock  can  be  detected  by 
attempting  to  reduce  the  state  graph,  (b)  deadlock  is  not 
possible  unless  there  is  a  cycle  in  the  state  graph,  and  (c) 
deadlock  is  present  if  there  is  a  knot  in  the  expedient  state 
graph. 

It  can  be  shown  that  Lemma  4.3  holds  for  general  resource 
systems.  That  is,  if  the  system  is  expedient  and  has  single 
unit  requests,  then  only  requests  for  units  which  are  not 
available  can  cause  deadlock. 

Deadlock  Detection  Algorithms 

As  is  true  for  consumable  resource  graphs,  the  order  of 
reductions  of  a  general  resource  graph  is  important,  and  there 
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is  no  known  fast 
arbitrary  general 
graph  is  expedient 
Algorithms  3.5  and 
testing  for  knots. 


algorithm  for  detecting  deadlock  in  an 
resource  graph.  If  the  general  resource 
and  has  only  single  unit  requests,  then 
3.6  provide  fast  deadlock  detection  by 
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P2 


Figure  5.  1  Example  of  a  state  in  a  general  resource  system. 
R2  is  a  consumable  resource  whose  only  producer  is  P2.  R1  and 
R3  are  reusable  resources  whose  total  units  are  tl  =  2  and  t3 
=  3.  The  available  units  are  rl  =  1,  r2  =  2,  and  r3  =  0.  The 
state  is  not  deadlocked  because  it  can  be  reduced  by  PI,  then 


by  P2,  and  then  by  P3. 
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5.2  Implementation  of  Bequest  and  Release 

The  theoretical  discussion  of  systems  using  request, 
acquisition,  and  release  operations  raises  the  question:  How 
should  these  operations  be  implemented  in  a  computer  system? 
In  the  rest  of  this  chapter  we  show  how  these  operations  can 
be  implemented  using  simpler  operations;  that  is,  given  a 
virtual  machine  which  has  facilities  for  parallel  processes 
and  basic  interprocess  communication  operations,  we  describe 
software  which  adds  resource  allocation  operations  to  the 
virtual  machine. 

Process  Pi  can  execute  an  acquisition  operation  if  and 
only  if  the  previous  operation  by  Pi  was  a  request.  Thus,  it 
is  not  necessary  to  implement  request  and  acquisition  as 
distinct  operations.  In  the  implementations,  we  will  combine 
the  two  operations  into  a  single  operation.  For  simplicity’s 
sake,  the  combined  operation  will  be  called  a  "request",  even 
though  it  is  actually  a  request  followed  by  an  acquisition. 

Basic  Communication  Operations 

To  the  hardware  of  a  modern  computer  must  be  added 
software  to  transform  the  computer  into  a  useful  and 
understandable  device.  One  of  the  first  facilities  which 
should  be  added  (via  software)  is  the  ability  to  have  several 
processes  execute  logically  in  parallel.  At  the  same  time 
that  parallel  processes  are  implemented,  there  should  be 
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implemented  basic  communication  operations  giving  processes 
the  following  abilities: 

(1)  A  process  should  be  able  to  become  blocked  until  some 
special  operation  is  (or  has  been)  executed  by  another 
process. 

(2)  A  process  should  be  able  to  execute  a  special 
operation  which  will  cause  a  blocked  process  to  be  no 
longer  blocked. 

These  abilities  are  provided  in  convenient  form  by  Lampson’s 
wakeup  switches  [1968]  together  with  his  Block  and  Wakeup 
operations. 

(See  Section  4.6  for  explanations  of  the  Block  and  Wakeup 
operations.  In  this  chapter  we  will  adopt  the  convention  that 
a  process  can  only  block  itself,  i.e. ,  a  process  executing  a 
Block  operation  must  specify  its  own  process  number.  The 
specification  of  a  process  number  will  be  omitted  in  the  Block 
operation,  implying  that  the  executing  process  is  to  be 
blocked.) 

In  addition  to  the  Block  and  Wakeup  operations,  it  is 
convenient  to  have  operations  which  allow  a  process  to  have 
exclusive  inspection  and  update  rights  for  the  system  data 
base,  so  that  a  process  can  be  sure  that  a  manipulation  of  the 
data  base  will  be  finished  before  another  process  can  access 
the  data  base.  As  Dijkstra  [  1965a]  puts  it,  we  need  to 
implement  ’’critical  sections”  so  that  there  will  be  ’’mutual 
exclusion”  among  processes  inspecting  the  data  base. 

We  will  assume  that  mutual  exclusion  has  been  implemented 
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by  two  operations,  called  Mutexbegin  and  Mutexend,  and  a 
switch  called  Mutex.  Me  describe  these  two  operations  as 
follows: 

Mutexbegin .  A  Mutexbegin  operation  by  process  Pi  is 
equivalent  to  a  single  unit  request  (followed  by  an 
acquisition)  for  a  reusable  resource  called  Mutex.  The 
Mutexbegin  operation  causes  Pi  to  be  blocked  until  the 
value  of  Mutex  is  strictly  positive  (which  is  until  Mutex 
=  1).  Once  Mutex  is  1r  then  Mutex  is  set  to  0,  and  Pi  is 
no  longer  blocked. 

Mutexend.  A  Mutexend  operation  by  process  Pi  is 
equivalent  to  a  single  unit  release  for  a  reusable 
resource  called  Mutex.  The  Mutexend  operation  changes  the 
value  of  Mutex  from  0  to  1. 

Me  will  assume  that  switch  Mutex  is  initialized  to  1  and  that 
within  any  process,  the  two  operations  are  always  executed  in 
Mutexbegin-Mu texend  pairs.  These  assumptions  guarantee  that 
Mutex  has  exactly  the  properties  of  a  single  unit  reusable 
resource. 

(Mutexbegin  and  Mutexend  are  equivalent  to  Dennis  and  Van 
Horn’s  lock  and  Unlock  operations  [1966].) 

In  Section  5.3,  implementations  of  the  request  and 
release  operations  are  given  in  terms  of  Block,  Makeup, 
Mutexbegin,  and  Mutexend. 

(Owicki  [1970]  has  shown  that  Mutexbegin  and  Mutexend  can 
be  implemented  using  Block  and  Makeup.  See  Appendix  1  for 
implementations  of  Block,  Makeup,  Mutexbegin,  and  Mutexend  in 
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PL/I.  As  implemented  in  Appendix  1 ,  the  Block  operation  can 
only  block  the  executing  process.) 

Re  mark.  When  only  Block  and  Makeup  have  been  implemented, 
we  can  consider  that  the  processes  have  only  explicit 
interactions,  and  we  can  analyze  the  process  interactions 
using  a  simplified  version  of  a  consumable  resource 
system.  (See  Section  4.6.)  When  Block,  Wakeup, 
Mutexbegin,  and  Mutexend  have  been  implemented,  we  can 
consider  that  the  processes  have  both  explicit  and 
implicit  interactions,  and  we  can  analyze  the  process 
interactions  using  a  simplified  version  of  a  general 
resource  system.  (The  only  reusable  resource  in  this 
general  resource  system  will  be  the  single  unit  reusable 
resource  called  Mutex.)  When  reguest  and  release  have 
been  implemented  (and  Block,  Wakeup,  Mutexbegin,  and 
Mutexend  are  not  allowed  except  in  request  and  release) , 
the  system  can  be  analyzed  using  a  general  resource 
system.  It  is  interesting  that  deadlock  can  be  analyzed 
at  several  levels  in  the  same  system.  For  example,  the 
analysis  can  be  made  upon  the  assumption  that  interactions 
are  caused  only  by  the  implementing  operations  (Block, 
Wakeup,  Mutexbegin,  and  Mutexend) ,  or  upon  the  assumption 
that  the  interactions  are  caused  only  by  the  implemented 
operations  (request  and  release).  It  is  an  interesting 
exercise  to  show  that  deadlock,  as  defined  by  the 
implementing  operations,  can  occur  only  when  deadlock,  as 
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defined  by  the  implemented  operations,  occurs. 

Distributed  and  Centralized  Allocators 

There  are  several  choices  to  make  before  implementing 
request  and  release.  One  of  the  first  choices  to  be  made  is 
whether  a  special  process  should  be  created  which  has  sole 
responsibility  for  allocating  resources  (we  will  call  this  a 
centralized  allocator)  or  whether  the  requesting  processes 
should  allocate  resources  directly  to  themselves  (we  will  call 
this  a  distributed  allocator. )  A  centralized  allocator  offers 
the  advantage  of  localizing  the  allocation  decisions,  and 
keeping  to  a  minimum  the  number  of  processes  which  access  the 
system  data  base.  This  advantage  is  rather  tenuous  when  a 
centralized  allocator  is  compared  to  a  distributed  allocator 
in  which  a  single  copy  of  a  reentrant  routine  is  used  to 
implement  reguest  and  release.  In  such  a  distributed 
allocator,  many  processes  access  the  data  base,  but  all  in  an 
identical  fashion.  A  distributed  allocator  offers  the 
advantage  of  eliminating  one  process  (the  central  allocator) , 
along  with  any  data  structures  required  to  communicate  with 
the  central  allocator. 

Algorithms  5.1  and  5.2  give  examples  of  distributed 
allocators,  and  Algorithm  5.3  gives  an  example  of  a 
centralized  allocator.  The  implementation  of  mutual  exclusion 
in  Appendix  1  is  another  example  of  a  centralized  allocator. 


Choosing  a  Deadlock  Strategy 
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The  system  designer  must  decide  whether  his  resource 
allocator  will  (1)  prevent  deadlock,  (2)  allow  deadlock  and 
detect  it,  or  (3)  allow  deadlock  and  let  the  system  ncrash”. 
Case  In  a  reusable  resource  system,  if  claims  for 

processes  are  known,  an  acquisition  policy  can  be  used  to 
prevent  deadlock.  Algorithm  5.1  uses  this  approach. 

Case  _2-  The  designer  can  allow  deadlock  to  occur  and  have 
the  allocator  test  for  deadlock  after  each  operation  which 
can  cause  deadlock.  Algorithm  5.2  uses  this  approach. 
Alternately,  the  designer  can  allow  deadlock  to  occur  and 
save  some  of  the  overhead  of  deadlock  detection  by  testing 
for  deadlock  only  occasionally.  Algorithm  5.3  uses  this 
approach. 

Case  3j,  The  designer  may  have  his  allocator  ignore 
deadlock  altogether,  and  rely  upon  the  operator  to  detect 
deadlock,  or  upon  the  processes  to  avoid  deadlock.  If  the 
designer  controls  the  writing  of  the  processes,  then  he 
may  impose  a  deadlock  policy,  such  as  the  ordered 
resources  policy,  thereby  guaranteeing  that  processes 


avoid  deadlock. 
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5.3  Examples  of  I mplementations 

In  this  section  we  present  implementations  of  the  request 
and  release  operations  in  terms  of  Block,  Wakeup,  Mutexbegin, 
and  Mutexend. 

Deadlock  Prevention  with  a  Distributed  Allocator 

Algorithm  5.1  is  a  very  simple  implementation  of  request 
and  release  with  deadlock  prevention.  The  algorithm  uses  a 
distributed  allocator  and  is  designed  for  a  system  with  only 
reusable  resources  where  each  process* s  claim  for  resources  is 
known.  The  simplicity  of  this  implementation  results  in  a 
certain  amount  of  inefficiency:  when  a  process  releases 
resources,  every  process  waiting  for  a  request  is  waked  up, 
regardless  of  whether  the  release  made  enough  units  available 
for  any  waiting  process’s  request  to  be  granted.  This 
inefficiency  will  not  be  important  if  most  requests  can 
-immediately  be  granted. 

In  Do-group  6  deadlock  prevention  is  accomplished  by  the 
method  suggested  by  Dijkstra  [1965a]  and  Haberraann  [1969]  (see 
Section  3.9).  When  an  acquisition  is  found  to  be  possible, 
the  units  are  temporarily  assigned,  and  a  test  is  made  to  see 
if  the  acquisition  is  safe.  If  the  acquisition  is  safe,  then 
the  acquisition  is  made  final;  otherwise,  it  is  retracted. 

If  Do-group  6  is  replaced  by  the  following: 

Do ; 

Assign  the  units; 

Set  G  to  say  reguest  is  granted; 
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End ; 

then  Algorithm  5.1  reverts  to  an  expedient  implementation  of 
request  and  release  without  deadlock  prevention  or  detection. 

Continuous  Deadlock  Detection  with  Single  Unit  Reguests 

Algorithm  5.2  is  a  very  efficient  implementation  of 
request  and  release  when  continuous  deadlock  detection  is 
required  and  only  single  unit  operations  are  allowed.  The 
system  may  have  both  reusable  and  consumable  resources.  Since 
the  operations  are  expedient,  by  Theorem  5.3,  deadlock  can  be 
detected  by  testing  for  knots.  As  was  observed  by  Section 
5.1,  only  requests  which  can  not  be  granted  can  cause 
deadlock.  Thus,  the  only  test  for  deadlock  is  in  statement  7 
of  the  request  procedure,  and  this  test  can  be  made  by 
Algorithm  3.6. 

Algorithm  5.2  is  more  efficient  than  Algorithm  5.1  in 
that  a  process  waiting  for  a  request  is  not  waked  up  after 
every  release.  Rather,  a  process  is  waked  up  only  when  a 
release  operation  assigns  the  requested  units  to  the  waiting 
process. 

Algorithm  5.2  is  also  more  efficient  than  Algorithm  5.1 
in  that  at  most  one  reduction  is  necessary  for  each  request. 
In  Algorithm  5.1  many  reductions  may  be  necessary  before 
granting  a  particular  reguest.  {These  reductions,  in 
statement  8  of  the  request  procedure,  determine  if  a  tentative 

assignment  is  safe.) 

Since  deadlock  can  occur  when  Algorithm  5.2  is  used,  a 
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Terminate  routine  is  included  in  provide  recovery  from 
deadlock.  The  simplest  method  of  recovery  is  used:  any 
process  whose  reguest  causes  deadlock  is  terminated.  If  the 
system  contains  only  reusable  resources  then  terminating  the 
requesting  process  will  completely  remove  the  deadlock  (see 
last  paragraph  of  Section  3.8),  and  Do-group  5  in  the 
Terminate  procedure  is  superfluous. 

If  the  system  contains  consumable  resources  then 
terminating  a  process  may  mean  eliminating  a  producer  of  a 
consumable  resource.  This  in  turn  may  mean  that  processes 
waiting  foe  such  a  consumable  resource  become  deadlocked, 
because  there  may  no  longer  be  any  way  for  the  waiting 
processes  to  acquire  their  reguested  units.  This  is  the 
reason  that  in  Do-group  5  of  the  Terminate  procedure, 
processes  in  addition  to  the  process  originally  causing  the 
deadlock  may  be  forced  to  terminate. 

Occasional  Test  for  Deadlock 

While  Algorithms  5.1  and  5.2  use  distributed  allocators. 
Algorithm  5.3  uses  a  centralized  allocator.  Thus,  in  addition 
to  request  and  release  procedures.  Algorithm  5.3  includes  a 
procedure,  called  the  Allocator,  which  implements  a  special 
cyclic  process. 

Deadlock  detection  in  Algorithm  5.3  is  accomplished  by 
another  special  cyclic  process  (not  shown) ,  which  we  will  call 
the  Detector.  The  Detector  can  be  implemented  as  follows: 
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Do  forever; 

Block; 

Mutexbegin; 

Test  for  deadlock; 

If  the  state  is  deadlocked  then 
Recover  from  deadlock; 

Mutexend ; 

End ; 

The  Detector  could  be  waked  up  at  regular  intervals,  or  at  any 
time  there  was  reason  to  suspect  that  processes  were 
deadlocked. 

If  the  system  has  only  reusable  resources  then  the 
Detector  can  use  Algorithm  3.2  to  test  for  deadlock  and 
Algorithm  3.12  to  recover  from  deadlock. 

If  the  system  has  consumable  resources,  then  Algorithm 
5.3  may  not  be  practical  because  of  the  overhead  required  by 
the  test  for  deadlock.  (This  test  would  be  done  by  Algorithm 
4.1  which  can  be  quite  slow.)  Still,  if  deadlock  detection  is 
required.  Algorithm  5.3  will  entail  much  less  overhead  than  is 
required  by  continuous  deadlock  detection. 

Algorithm  5.3  leaves  to  an  unspecified  routine,  called 

i 

the  Scheduler,  the  decision  of  which  requests  to  grant.  The 
only  restraint  on  the  Scheduler  is  that  it  can  delay  the 
granting  of  a  request  for  available  units  only  for  a  finite 
time.  If  the  Scheduler  violates  this  restraint,  it  will 
introduce  deadlock  which  will  not  be  detected  by  the  reduction 
algorithms.  (This  restraint  is  equivalent  to  requiring  that 
the  Allocator  obey  the  "eventuality  condition",  as  defined  in 
[  Holt  1971  ].) 

If  the  Scheduler  is  not  expedient,  i.e.,  if  requests  for 
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available  units  are  not  necessarily  granted  immedia tedly ,  then 
the  Scheduler  must  guarantee  that  the  Allocator  is  always 
waked  up  after  a  finite  time  of  being  blocked.  This  can  be 
guaranteed  by  having  a  special  timing  process  wake  up  the 
Allocator  at  fixed  time  intervals.  The  simpler  situation  is 
when  the  Scheduler  is  expedient,  and  when,  as  a  result,  no 
special  timing  process  is  required. 

One  of  the  attractive  features  of  a  centralized  allocator 
such  as  Algorithm  5.3  is  the  simplicity  and  symmetry  of  the 
request  and  release  procedures.  These  two  procedures  are 
practically  identical,  and  could  be  implemented  as  the  same 
procedure  with  the  addition  of  a  switch  local  to  each  process 
used  to  distinguish  which  operation  is  being  executed. 

An  efficient  way  to  maintain  the  system  state  is  to 
maintain  the  request  queues  for  each  resource  in  order  of 
request  size  and  to  maintain  a  wait  count  for  each  process  as 
described  in  Section  3.5.  As  soon  as  a  process's  wait  count 
reaches  zero,  the  process  should  be  added  to  a  "ready  queue" 
from  which  the  Scheduler  picks  processes  to  receive  requests. 
If  the  ready  queue  is  maintained  in  order  of  process 
priorities,  then  the  Scheduler  need  only  pick  the  first 
process  on  the  ready  queue. 

The  Effective  Deadlock  Problem 

Algorithms  5.1,  5.2,  and  5.3  illustrate  how  the  theoretic 
results  of  Chapters  3,  4,  and  5  can  be  used  in  a  practical 
computer  system.  The  systems  designer  should  bear  in  mind 
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that  the  deadlock  prevention  and  detection  techniques  used  in 
these  algorithms  will  be  correct  only  if  request  is  the  sole 
operation  which  can  cause  a  process  to  be  blocked.  If  a 
process  were  allowed  to  execute  a  Block  operation  (which  was 
not  part  of  a  request  or  release  operation) ,  then  deadlock 
could  occur  which  would  be  neither  prevented  nor  detected. 

As  was  established  in  Chapter  2,  even  if  deadlock  never 
occurs,  it  does  not  necessarily  follow  that  all  processes  will 
continue  to  their  next  operations.  That  is,  effective 
deadlock  is  still  possible.  Even  though  a  process  which 
executes  a  request  in  Algorithm  5.1  can  never  deadlock,  it  is 
still  logically  possible  that  the  process  could  execute 
Do-group  3  in  the  request  procedure  an  infinite  number  of 
times  without  finding  that  its  request  could  be  safely 
granted.  (See  [Holt  1971]  for  a  method  of  preventing 
effective  deadlock  in  Algorithm  5.1.) 

In  Algorithm  5.3  even  when  deadlock  does  not  occur,  it  is 

i 

possible  that  the  Allocator  may  never  wake  up  a  particular 
requesting  process  because  the  units  requested  may  never 
simultaneousl y  be  available. 

In  Algorithm  5.2  there  is  an  easy  way  to  prevent 
effective  deadlock  which  is  not  true  deadlock.  Suppose  the 
longest  waiting  process  always  receives  a  released  unit,  i.e., 
suppose  that  the  (single  unit)  request  queues  are  FIFO.  Then 
the  designer  can  enforce  the  rule  that  a  producer  of  a 
consumable  resource  or  a  holder  of  a  reusable  resource  is 
allowed  to  execute  only  a  fixed  maximum  number  of  operations 
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1.  Request:  Procedure; 

2.  Set  switch  G  to  say  request  not  yet  granted; 

3.  Do  while  switch  G  says  request  not  granted; 

4.  Mutexbegin; 

5.  If  enough  units  are  available  to  grant  request  then 

6.  Do; 

7.  Tentatively  assign  the  units; 

9.  If  tentative  assignment  is  safe  then 

9.  Set  G  to  say  request  is  granted; 

10.  Else 

11.  Retract  the  tentative  assignment; 

12.  End; 

13.  If  switch  G  says  request  not  granted  then 

14.  Add  this  process  to  list  waiting  for  request; 

15.  Mutexend; 

16.  If  switch  G  says  request  not  granted  then 

17.  Block  until  waked  up  by  Release; 

13.  End; 

19.  End  Request; 


1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 
9. 


Release:  Procedure; 

Mutexbegin ; 

Add  released  units  to  available  units; 

Do  for  each  process  Q  on  list  waiting  for  request; 
Remove  Q  from  list  waiting  for  a  request; 
rfakeup  process  Q; 

End; 

Mutexend ; 

En  d  Release; 


Algorithm  5.1  A  distributed  allocator  with  deadlock 
prevention.  This  system  has  only  reusable  resources  and  each 
process  has  a  claim  for  its  maximum  requirements  of  each 


resource 


SECTION  5.3  180 


1.  Request:  Procedure; 

2.  Mutexbegin; 

3.  Set  switch  G  to  say  whether  requested  unit  available; 

4.  If  switch  G  says  requested  unit  is  available  then 

5.  Assign  the  unit  to  the  process; 

6.  Else 

7.  Set  switch  D  to  say  whether  this  process  is 

deadlocked ; 

8.  Mutexend; 


9. 

If  switch  G 

says  unit  is  not  available  then 

10. 

Do ; 

11. 

If  switch 

D  says  this  process  is  deadlocked  then 

12. 

Terminate 

this  process; 

13. 

Block  until  waked  up  by  Release  or  Terminate; 

14. 

If  wakeup 

was  by  Terminate  then 

15. 

Terminate 

this  process; 

16. 

End ; 

17. 

End  Request; 

1.  Release:  Procedure; 

2.  Mutexbegin; 

3.  If  a  process  Q  has  reguested 

4.  Do; 

5.  Assign  the  unit  to  process 

6.  Wakeup  process  Q; 

7.  End; 

8.  Else 

9.  Add  the  released  unit  to  the 

10.  Mutexend; 

11.  End  Release; 

1.  Terminate:  Procedure; 

2.  Do  for  each  reusable  unit  D  assigned  to  this  process; 

3.  Release  unit  0; 

.  4.  End; 

5.  Do  for  each  resource  R  produced  by  this  process; 

6.  Mutexbegin; 

7.  Remove  this  process  from  list  of  producers  of  R; 

8.  If  seme  process  Q  has  a  request  for  R  then 

9.  If  process  Q  is  now  deadlocked  then 

10.  Do  for  each  process  Q  with  a  request  for  R; 

11.  Set  a  switch  telling  Q  to  terminate; 

12.  Wakeup  Q; 

13.  End; 

14.  Mutexend; 

15.  End; 

16.  Exit;  /*This  process  ceases  to  exist.*/ 

17.  End  Terminate; 

Algorithm _ 5_.2  Expedient  distributed  allocator  with  continuous 

deadlock  detection.  Resources  may  be  both  reusable  and 
consumable.  Requests  and  releases  are  for  single  units. 


this  resource  then 
Q; 

available  units; 


SECTION  5.3 


181 


1.  Request:  Procedure; 

2.  Mutexfcegin; 

3.  Add  this  process  to  list  of  reguesters; 

4.  Mutex end; 

5.  Makeup  Allocator; 

6.  Block  until  waked  up  by  Allocator; 

7.  End  Segues t; 


1.  Release:  Procedure; 

2.  Mutexbegin; 

3.  Add  this  process  to  list  of  releasers; 

4.  Mutexend; 

5.  Makeup  Allocator; 

6.  Block  until  waked  up  by  Allocator; 

7.  End  Release; 


1- 

2. 

3. 

4. 

5. 

6. 

7. 

8. 
9. 

10. 

11. 

12. 

13. 

14. 

15. 

16. 

17. 

18. 

19. 

20. 
21. 
22. 


Allocator:  Procedure; 

/♦This  is  a  special  cyclic  process.*/ 

Do  forever; 

Block  until  waked  up  by  Reguest  or  Release; 
Mutexbegin ; 

Do  for  each  process  P  on  list  of  reguesters; 
Remove  process  P  from  list  of  reguesters; 
Update  system  state  by  request  by  P; 

End  ; 

Do  for  each  process  P  on  list  of  releasers; 
Remove  process  P  from  list  of  releasers; 

Add  units  released  by  P  to  available  units; 
Makeup  process  P; 

End  ; 

Let  Scheduler  pick  process  P  whose  request 
can  be  granted; 

Do  while  P  is  not  null; 

Allocate  requested  units  to  process  P; 
Makeup  process  P; 

Let  Scheduler  pick  process  P  whose  request 
can  be  granted; 

End  ; 

Mutexend ; 

End ; 

End  Allocator; 


Algorithm _ 5^  3 

detection.  The 
procedures  are 


Centralized 
Scheduler 
not  shown. 


allocator  with  occasional  deadlock 
and  the  detection  and  recovery 


Resources  may  be  both  consumable 


and  reusable 


■ 
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CHAPTER  6.  A  MODEL  USING  FLOW  CHARTS 

In  Chapters  3,  4,  and  5  we  were  not  concerned  with  the 
“internal  structure"  of  processes.  The  most  information  which 
was  known  about  a  process  was  which  resources  could  be 
requested  and  released  by  the  process.  For  example,  in  claim 
limited  consumable  resource  systems,  all  that  was  known  about 
a  process  was  which  resources  could  be  produced  and  consumed 
by  the  process. 

It  may  well  be  that  much  more  information  about  the 
processes  is  available.  For  example,  if  the  systems  designer 
has  written  all  the  programs  for  a  real  time  system  then  he 
will  have  at  hand  a  complete  specification  of  all  processes  in 
terms  of  their  flow  charts  (or  programs).  In  this  chapter  we 
will  investigate  how  the  additional  information  contained  in 
the  process  flow  charts  can  be  used  in  detecting  and 
preventing  deadlock. 

The  roost  important  new  results  in  the  chapter  are 
theorems  stating  that  when  the  process  flow  charts  are 
incorporated  into  the  model  (1)  it  is  decidable  if  a  state  is 
deadlocked,  (2)  it  is  decidable  if  the  available  units  are 
bounded,  and  (3)  given  that  the  available  units  are  bounded, 
it  is  decidable  if  a  state  is  safe  from  deadlock.  The 
following  interesting  question  is  left  open:  Is  it  decidable 
if  a  system  is  safe  when  it  is  not  required  that  the  available 


units  be  bounded? 
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6.1  A  Closer  Look  at  Processes 


In  this  section  we  give  an  informal  introduction  to  a 
model  of  systems  which  includes  the  process  flow  charts;  in 
Section  6.2  this  model  will  be  formalized.  This  model,  called 
"semaphore  systems",  is  closely  related  to  Slutz's  "flow  graph 
schemata"  [1968]  and  to  Karp  and  Miller's  "counter  schemata” 
[1969],  and  it  can  be  applied  directly  to  Dijkstra's 
"cooperating  sequential  processes"  [  1965a]. 


An  Example  of  a  System 


As  we  explained  in  Section  4.6  a  "semaphore"  is  a  global 
counter  which  is  used  for  synchronizing  processes  in  computer 
systems.  Dijkstra  defined  semaphores  and  he  has  given 
examples  of  systems  of  processes  using  semaphores  for 


sy  nchronization  [  1965a], 


As 


we  have  stated  before. 


"semaphores"  and  "resources"  have  the  same  behavior,  and  we 
will  use  the  terms  "semaphore"  and  "resource"  interchangeably 
in  this  chapter. 

We  will  introduce  semaphore  systems  by  showing  how  a 
semaphore  system  can  be  used  to  model  one  of  Dijkstra's 
examples.  In  Figure  6.1,  we  give  one  of  Dijkstra's  examples 
[ pg.  34 , 1965a  ]  as  represented  by  flow  charts.  (The  example  is 
originally  given  in  Algol.)  In  the  figure  we  have  written 
"Request (M) "  to  mean  the  process  requests  one  unit  of  resource 
M;  "Request  (M)"  is  equivalent  to  Dijkstra's  notation  " P  ( M) " . 


Sim  ilar  ly , 


"Release  (M)"  is  a  release  for  one  unit  of  M  and  is 
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equivalent  to  Dijkstra’s  notation 

In  Figure  6.  1  there  are  two  processes,  the  Producer  and 
the  Consumer.  It  is  the  job  of  the  Producer  to  produce 
portions  of  data,  to  put  these  portions  of  data  into  buffers, 
and  to  signal  the  Consumer  when  each  new  portion  is  available. 
The  two  processes  use  two  semaphores  for  synchronization; 
these  semaphores  are  called  K  (for  mutual  exclusion)  and  F 
(for  full  buffer).  Semaphore  M  implements  mutual  exclusion  so 
that  each  process  can  add  a  portion  of  data  to  a  buffer  (or 
remove  a  portion  of  data  from  a  buffer)  without  interference 
from  the  ether  process.  Semaphore  F  is  used  to  maintain  the 
count  of  the  number  of  buffers  containing  data,  and  causes  the 
Consumer  to  wait  when  there  are  no  portions  ready  to  be  used. 

The  system  in  Figure  6.1  is  started  with  M  =  1  and  F  =  0, 
with  the  Producer  about  to  execute  flow  chart  box  pi,  and  with 
the  Consumer  about  to  execute  flow  chart  box  cl.  It  is  easy 
to  show  that  the  system  can  not  deadlock,  i.e.,  it  is  easy  to 
show  that  if  one  process  becomes  blocked  due  to  a  request, 
there  will  always  be  a  sequence  of  operations  by  the  other 
process  which  will  leave  the  first  process  not  blocked.  (It 
is  a  little  disturbing  to  observe  that  if  boxes  cl  and  c2  are 
interchanged  in  the  Consumer  flow  chart,  then  the  system  is  no 
longer  safe  from  deadlock.) 


Introduction  to  Semaphore  Systems 

As  Dijkstra  has  shown,  semaphores  bring  a  large  degree  of 
simplicity  and  symmetry  to  process  synchronization  and 
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resource  allocation;  however,  the  problems  of  determining  if  a 
system  is  safe  from  deadlock  and  determining  if  a  state  is 
deadlocked  remain  difficult.  Our  purpose  in  defining  and 
investigating  semaphore  systems  is  to  clarify  these  problems 
and  their  solutions. 

In  a  semaphore  system,  the  instruction  for  each  flow 
chart  box  will  be  an  m-dimensional  vector,  where  m  is  the 
number  of  semaphores  in  the  system.  In  the  example  of  Figure 
6.1,  ra  =  2,  and  each  instruction  will  be  a  2-dimensional 
vector.  If  the  j-th  element  of  the  instruction  (vector)  is 
negative,  the  instruction  will  represent  a  request  for  the 
j-th  semaphore  (resource).  If  we  consider  M  to  be  the  first 
semaphore  and  F  to  be  the  second  semaphore,  then  the 
instruction  "Request  (R)"  will  become  (-1,0)  in  a  semaphore 
system.  Similarly,  "Release (M) ”  will  become  (1,0).  Each 
instruction  which  does  not  request  or  release  semaphores  will 
be  considered  a  "null  instruction"  and  will  become  the  vector 
.(0,0)  in  a  semaphore  system.  See  Figure  6.2  for  Dijkstrafs 
example  as  represented  by  a  semaphore  system. 

The  state  in  a  semaphore  system  is  given  by  a  list  of 
those  instructions  just  executed  by  each  process  together  with 
a  list  of  the  values  ("available  units")  of  all  the 
semaphores.  For  example,  the  starting  state  in  Figure  6.2  is 
{ (p5,c5) ,  ( 1 , 0) )  which  means  that  the  Producer  is  about  to 
execute  box  pi,  the  Consumer  is  about  to  execute  box  cl,  M  = 
1,  and  F  =  0.  In  this  example,  the  elements  of  all 

(vectors)  are  either  -1,0,  or  1;  however,  in 


instructions 
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general  we  will  allow  an  instruction  in  a  semaphore  system  to 
be  any  m-dimensional  integer  vector. 

In  a  semaphore  system,  a  process  executes  an  operation  by 
adding  the  next  instruction  (vector)  in  its  flow  chart  to  the 
’•available  units  vector”  of  the  semaphores.  For  example,  if 
the  system  in  Figure  6.2  is  in  state  (  (pi ,c5) ,  (1 ,0) )  ,  then 
process  PI  (the  Producer)  can  execute  instruction  p2  (which  is 
(-1,0))  and  thereby  change  the  state  to  (  (p2  ,c5)  ,  (0,  0)  )  .  A 
process  is  not  blocked  if  and  only  if  the  sum  of  its  next 
instruction  and  the  available  units  vector  is  nonnegative. 
For  example,  in  state  (  (p5,c5) ,  { 1 , 0) )  the  Consumer  is  blocked 
because  its  next  instruction  is  (0,-1). 

In  a  semaphore  system,  the  flow  chart  for  each  process  is 
a  directed  graph.  There  are  two  important  restrictions 
imposed  on  these  graphs.  The  first  restriction  is  that  if  the 
instruction  for  a  node  (flow  chart  box)  is  a  request  (i.e.,  if 
at  least  one  element  of  the  instruction  vector  is  strictly 
negative) ,  then  each  father  of  the  node  must  have  exactly  one 
son.  This  restriction  is  equivalent  to  requiring  that  a 
process  must  first  ’•request”  and  then  ’’acquire”  units.  That 
is,  if  a  process  is  to  decrement  the  available  units  in  its 
next  operation,  then  we  wish  to  know  from  the  system  state 
exactly  which  semaphores  will  be  decremented  by  which  amounts. 
The  second  restriction  is  that  there  must  be  a  path  from  every 
node  in  a  flow  chart  to  every  other  node  in  the  flow  chart 
(i.e.,  the  directed  graph  must  be  ’’strongly  connected”).  Most 
of  the  results  given  below  are  true  with  or  without  these 
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restrictions,  We  include  these  restrictions  primarily  (a)  to 
make  request  operations  correspond  to  our  definitions  of 
request  operations  in  previous  chapters,  and  (b)  to  force  the 
processes  to  behave  like  cyclic  system  processes,  such  as 
those  in  most  of  Dijkstra's  examples  [1965a]. 

Null  Instructions  and  Decidability 

In  semaphore  systems,  all  instructions  which  do  not 
change  the  available  units  of  the  semaphores  are  considered  to 
be  null,  that  is,  the  instructions  are  represented  by  vectors 
of  zeros.  This  is  a  simplification  which  is  both  a 
convenience  and  a  necessity.  It  is  a  convenience  because  as 
long  as  every  instruction  not  involving  semaphores  takes  a 
finite  execution  time  and  has  a  unique  succeeding  instruction 
in  the  flow  chart,  then  we  gain  no  information  about  the 
possibility  of  deadlock  by  knowing  what  the  instruction 
actually  does.  On  the  other  hand,  if  an  instruction  has 
several  succeeding  instructions  in  the  flow  chart,  and  if  the 
instruction  determines  which  succeeding  instruction  will  be 
executed  next  by  the  process,  then  most  questions  about 
deadlock  become  undecidable.  For  example,  in  Figure  6.3 
instruction  si  simulates  one  operation  in  Turing  machine  TM, 
and  branches  back  to  si  if  and  only  if  TM  does  not  halt. 
Since  TM  is  an  arbitrary  Turing  machine,  it  is  not  decidable 
if  TM  halts,  and  thus,  it  is  not  decidable  if  instruction  s2 
will  ever  be  executed.  The  process  called  Waiter  will  be 
blocked  waiting  for  semaphore  H  until  instruction  s2  is 
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executed ,  and  hence,  it  is  not  decidable  (1)  if  the  system  is 
safe  or  (2)  if  state  (  {s3 , w  1 )  ,  (0)  )  is  deadlocked. 

The  system  in  Figure  6.3  can  be  changed  to  a  semaphore 
system  by  changing  the  instructions  for  si,  s2,  s3,  and  wl  to 
the  vectors  (0),  (1),  (0)/  and  (-1),  respectively.  In  the 
semaphore  system,  state  ( <s3 , w 1) ,  (0) )  is  not  a  deadlock  state 
because  operations  by  the  Simulator  can  change  the  state  to 
{  (s2 , w  1 )  ,  ( 1 ) )  in  which  the  Waiter  is  not  blocked.  Thus,  a 
state  may  not  be  deadlocked  in  a  semaphore  system  even  though 
the  corresponding  state  is  deadlocked  in  the  system  which  is 
being  modeled.  However,  if  a  state  in  a  semaphore  system  is 
deadlocked,  then  necessarily  the  corresponding  state  is 
deadlocked  in  the  system  which  is  being  modeled.  This  is  true 
because  the  semaphore  system  is  able  to  "mimic"  all  operations 
(and  more)  of  the  original  system. 

Self  Regulating  States 

i 

If  the  system  in  Figures  6.1  and  6.2  is  started  in  state 
{  (p5,c5)  ,  (1  ,0)  )  ,  then  it  is  safe  from  deadlock.  However,  it 
is  not  "safe  from  overflow"  in  that  the  Producer  can 
continuously  execute  operations  and  force  the  value  of 
semaphore  F  to  exceed  any  given  bound.  In  an  actual  computer 
system,  the  value  of  F  will  be  placed  in  a  word  in  storage, 
and  if  the  value  of  F  exceeds  the  maximum  value  for  a  word, 
then  the  semaphore  can  not  behave  properly.  More  than  likely, 
a  semaphore  will  represent  a  resource  which  is  (or  which 
requires)  physical  storage,  and  thus. 


an  unbounded  value  of  a 
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semaphore  will  require  an  unbounded  amount  of  physical 
storage,  The  point  is  that,  while  it  is  desirable  to  show 
that  a  state  is  safe,  it  is  also  desirable  to  show  that  the 
semaphores  will  all  remain  bounded. 

We  will  say  a  state  is  "self  regulating”  if  it  is  both 
safe  from  deadlock  and  "safe  from  overflow".  We  formalize 
this  definition  in  the  following: 

We  define  the  reachability  set  of  state  S  in  system  Z, 
written  RS(S,Z),  as  the  set  of  all  states  T  such  that  in 
Z,  S  -*->  T.  If  there  is  no  ambiguity  about  the  system  in 
guestion,  we  will  write  simply  RS(S)  instead  of  RS(S,Z). 
We  will  say  that  state  S  is  self  regulating  if  S  is  safe 
and  HS  (S)  is  finite.  If  one  or  more  states  in  a  system 
are  self  regulating,  then  the  system  is  said  to  be  self 
req  ulating. 

Notice  that  the  definitions  of  "reachability  set"  and  "self 
regulating"  are  not  confined  to  semaphore  systems.  It  is 
easily  shown  that  in  reusable  resource  systems,  every  safe 
state  is  self  regulating  and  in  consumable  resource  systems, 
no  safe  state  (and  thus  no  state)  is  self  regulating. 

In  semaphore  systems,  there  are  a  finite  number  of  boxes 
in  each  flow  chart,  and  thus,  a  safe  state  is  not  self 
regulating  if  and  only  if  some  semaphore  is  not  bounded.  As 
we  observed,  in  the  system  in  Figures  6.1  and  6.2,  semaphore  F 
is  not  bounded.  Thus,  while  system  state  ( ( p 5 ,c5) ,  (1 , 0) )  is 
safe,  it  is  not  self  regulating. 

Figure  6.4  shows  a  system  which  is  self  regulating. 
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{Figure  6.4  is  translated  to  flow  chart  form  from  another  of 
Di jkstra’s  examples  [  pg. 39,  1965a ].  )  This  system  is  similar  to 
the  system  in  Figure  6. 1  with  the  difference  that  there  are  a 
finite  number  of  buffers  which  can  be  filled  by  the  Producer 
before  the  Producer  must  wait  for  an  empty  buffer.  Initially 
all  buffers  in  the  system  are  empty.  Each  time  the  Consumer 
empties  a  buffer,  the  Consumer  releases  an  empty  buffer  which 
can  be  used  by  the  Producer.  Another  semaphore,  called  E,  has 
been  added  to  the  system  to  keep  track  of  the  number  of  empty 
buffets.  Given  that  the  system  starts  in  state 
{  (p6#c6)  ,  { 1 ,0 , e)  )  where  e  >  1,  {i.e.,  M  =  1,  F  =  0,  and  E  =  e 
>  1),  it  can  be  proved  that  deadlock  can  not  occur,  that  M  is 
bounded  by  1,  and  that  F  and  E  are  bounded  by  e.  (The  proof 
follows  from  the  fact  that  for  any  given  e,  e  >  1,  the  states 
accessible  frcm  state  { (p6,c6) ,  (1 , 0,e) )  can  be  exhaustively 
listed.)  Thus,  state  (  (p6 ,c6 ) ,  ( 1 , 0 ,e) )  is  a  self  regulating 


state. 
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figure  6.__1  Dijkstra's  example  of  a  producer  and  consumer.  F 
gives  the  number  of  data  portions  produced  but  not  yet 
consumed.  a  is  used  to  implement  mutual  exclusion.  F  and  M 
are  initialized  to  0  and  1,  respectively. 
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Fig ure  6. 2  Dijkstra's  example  as  a  semaphore  system.  The 
initial  state  of  the  system  is  (Q,r)  =  (  (p5  ,  c5)  ,  ( 1 , 0)  )  .  The 
initial  state  is  safe  but  not  self  regulating. 
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Figure  6.4  Example  of  a  self  regulating  system. 
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6.2  Semaphore  Systems 
Preliminary  Definitions 

In  this  section  we  give  a  formal  definition  of  semaphore 
systems.  First  we  give  a  number  of  preliminary  definitions. 
For  m-diraensional  vectors  K  =  (K 1 , K2 , . . . , Km)  and  L  = 
(LI  ,L2,...,Lm)  we  write 

L  <  K 

if  Lj  <  Kj  for  1  <  j  <  m.  We  write 

L  <  K 

if  L  <  K  and  for  some  j,  Lj  <  Kj.  Similarly,  we  write 

L  >  K 

if  Lj  >  Kj  for  1  <  j  <  m,  and  we  write 

L  >  K 

if  L  >  K  and  for  some  j,  Lj  >  Kj.  We  will  write  a  vector  of 
zeros,  (0,0, ...,0)  as#  simply,  0.  If  all  elements  of  a  vector 
are  nonnegative  then  we  will  say  the  vector  is  nonnegati ve . 

We  define  the  instructions  for  each  node  (box)  in  a  flow 
chart  as  follows: 

An  in-semaphore  instruction  (or  simply,  an  instruction)^  is 
any  m-dimensional  integer  vector  I.  If  I  >  0,  then  we 
call  I  a  release  instruction;  if  I  =  0,  we  call  I  a  null 
instruction;  otherwise  we  call  I  a  request  instruction. 
Notice  that  I  is  a  request  instruction  if  and  only  if  at  least 
one  element  of  I  is  strictly  negative,  and  that  even  though  I 
is  a  request  instruction,  some  elements  of  I  may  be  strictly 


positive. 
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We  call  each  flow  chart  a  ’’process  graph”.  Before 
defining  process  graphs,  we  need  to  define  ’’strongly 
connected” : 

A  directed  graph  is  strongly  connected  if  and  only  if  for 
any  two  nodes  a  and  b,  there  is  a  path  directed  from  a  to 

b. 


We  now  define  ’’process  graphs”: 

An  m-semaphore  process  graph  (or  simply,  a  process  graph) 
is  any  finite  strongly  connected  directed  graph  such  that 

(1)  associated  with  each  node  is  an  m-seraaphore 
instruction, 

(2)  at  least  one  node  in  the  graph  has  associated  with  it 
an  instruction  which  is  not  null, 

(3)  if  the  instruction  associated  with  a  node  is  a 
request,  then  each  father  of  the  node  has  exactly  one  son, 
and 

(4)  for  given  nodes  Qi  and  Qj,  there  is  at  most  one  edge 
in  the  graph  directed  from  Qi  to  Qj. 


Semaphore  Systems 

We  now  define  ’’semaphore  systems”: 

An  n  b_y  jn  semaphore  system  (or  simply,  a  semaphore  e  m}_ 

is  comp le t el y  ch ar act er ized  by  a  set  of  ro— sema phore  graphs 
{P 1 , P2 , - . - , Pn] .  The  set  of  semaphore  graphs  must  have  the 
property  that  for  each  j,  1  ^  j  -  m,  there  exists  a  node 
in  a  process  graph  with  instruction  I  -  (1 1 ,12, • - • ,1 m)  and 

there  exists  a  node  in  a  process  graph  with  instruction  K 
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-=  {K1,K2,  .  .  .  ,Km)  such  that  Ij  <  0  <  Kj. 

We  have  required  that  for  each  semaphore,  at  least  one 
instruction  in  the  system  can  increment  the  semaphore,  and  at 
least  one  instruction  can  decrement  the  semaphore.  This 
corresponds  to  the  requirement  in  claim  limited  consumable 
resource  systems  that  each  resource  must  have  a  nonempty  set 
of  producers  and  a  nonem pty  set  of  consumers.  We  include  this 
requirement  for  semaphore  systems  primarily  so  that  vie  can  use 
claim  limited  consumable  resource  systems  to  determine 
deadlock  properties  of  semaphore  systems  (see  Section  6.3). 

We  now  define  the  set  of  states  of  a  semaphore  system: 

The  set  cf  states  SIGMA  of  an  n  by  m  semaphore  system  is 
the  set  of  all  states  S  such  that  S  =  (Q,r)  = 
( (Q1#Q2,-  .  .  ,Qn)  ,  (r  1 ,  r2, .  .  .  ,  rm)  )  where 

(1)  Qi  is  a  node  in  process  graph  Pi  (1  <  i  <  n) ,  and 

(2)  rj  is  any  nonnegative  integer  (1  <  i  <  m)  . 

We  will  call  Q  =  ( Q 1 , Q2,. .. , Qn)  the  process  node  vector  and  we 

will  call  r  =  (r 1 ,r 2 , . . . , rm)  the  available  units  vector. 

We  will  define  the  processes  in  a  semaphore  system  by 
describing  their  operations.  Let  S  and  S'  be  states  in  a 
semaphore  system  where  S  -  (  <Q  1 , . . . , Qi,. . . , Qn) , r)  and  S*  = 
{(Ql*,...,Qi*,...,Qn#) ,r  * )  -  If  (1)  (Qi,Qi*)  is  an  edge  in 
process  graph  Pi,  (2)  Qk  -  Qk1  for  k  *  i ,  and  (3)  r*  =  r*I  >  0 
where  I  is  the  instruction  for  node  Qi*,  then 

S  -i->  S». 

The  operation  S  -i->  S’  is  called  a  release  operation,  a  null 
operation,  or  a  request  operation,  according  to  whether  I  is  a 
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release  instruction,  a  null  instruction,  or  a  request 
instruction.  Notice  that  when  the  state  is  S*,  node  Qi* 
corresponds  to  the  last  instruction  (not  to  the  next 
instruction)  executed  in  process  graph  Pi. 

It  follows  easily  from  the  description  of  operations  in 
semaphore  systems  and  the  definition  of  ’’blocked11  in  Section 
2.2  that: 

Process  Pi  is  blocked  in  state  S  =  ({Q1,...,Qi, _ ,Qn)  , 

^  2 ,  •  •  •  ,  ria )  )  if  and  only  if  the  only  son  of  node  Qi  is 

Qi*  and  the  instruction  for  Qi*  is  a  request  I 
(1 1 ,12, .. . ,Im)  where  for  some  j,  rj  +  Ij  <  0. 

That  is  process  Pi  is  blocked  if  and  only  if  the  next 
instruction  in  Pi  is  a  request  for  more  units  than  are 
presently  available. 

A  Special  Case  of  Semaphore  Systems 

We  will  show  that  in  a  highly  restricted  subcase  of 

i 

semaphore  systems,  simple  tests  exist  to  determine  if  a  system 
is  safe.  This  subcase  will  correspond  to  the  subcase  of  a 
reusable  resource  system  having  a  single  type  of  resource  and 
only  single  unit  reguests  (see  Section  3.6). 

We  will  say  a  semaphore  system  has  single  unit  requests 
if  for  every  request  instruction  I  =  (1 1 ,12,. - • ,Ira)  there 
exists  j  such  that  Ij  =  -1  and  Ik  =  0  for  k  *  j.  An  n  by  m 
semaphore  system  is  said  to  have  a  single  type  of  resource  if 
m  =  1. 


In  Figure  6.5  we  give  three  examples  of  semaphore  systems 
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with  a  single  type  of  resource  and  single  unit  requests.  In 
example  (a)  of  the  figure,  it  is  obvious  that  the  system  is 
safe  but  not  self  regulating.  In  example  (b)  ,  it  is  obvious 
that  the  system  is  both  safe  and  self  regulating.  Example  (c) 
is  interesting  because  at  first  glance  it  may  appear  that  it 
is  a  safe  system;  one  might  reason  (erroneously)  that  (c)  is 
similar  to  (b) ,  and  (b)  is  safe,  so  { c)  should  be  safe. 
Unfortunately,  example  (c)  is  not  a  safe  system,  as  the  reader 
may  wish  to  verify.  In  Lemma  6.1  we  give  simple  tests  to 
determine  which  of  these  examples  are  safe. 

Lemma  5.1  Let  SS  be  an  n  by  1  semaphore  system  with  single 
unit  requests.  SS  is  safe  if  and  only  if  either  of  the 
following  is  true: 

(a)  some  process  graph  has  no  request  instructions,  or 

(b)  for  every  cycle  (Q1,Q2,. . . ,Qx,Q1)  in  every  process 
graph,  the  sura  of  the  instructions  for  Q1,  Q2,  ...,  and  Qx 
is  nonnegative. 

Suppose  neither  (a)  nor  (b)  is  true  and  process 
graph  Pi  has  a  cycle  (Q 1 , Q2 , . . . , Qx , Q 1 )  such  that  the  sum 
of  tne  instructions  for  Q1,  Q2,  and  Qx  is  strictly 
negative.  We  will  show  that  for  any  state  S,  S  -*->  S' 
where  S*  is  a  deadlock  state.  S  is  changed  to  S*  as 
follows-  First,  all  processes  except  Pi  execute 
instructions  until  their  next  instructions  are  requests. 
Next,  Pi  executes  instructions  in  cycle  (Q 1 , Q2, . . . , Qx, Q  1) 
until  there  are  zero  available  units  and  the  next 
instruction  for  Pi  is  a  reguest.  The  resulting  state.  S’, 
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is  a  deadlock  state  because  all  processes  are  blocked. 
Therefore  if  neither  (a)  nor  (b)  is  true,  then  SS  is  not 
safe. 

tfe  will  finish  the  proof  by  showing  that  if  either 
(a)  or  (fc)  is  true,  then  the  system  is  safe.  If  (a)  is 


true,  then  the  system 

is 

safe  because  at 

least 

one 

process,  call  it  Pi, 

has 

release  instructi 

ons  but 

no 

request  instructions. 

Thus, 

from  any  state. 

process 

Pi 

can  execute  null  instructions  until  it  executes  a  release 
instruction.  Since  the  maximum  request  is  for  one  unit, 
this  release  will  leave  all  processes  not  blocked.  If  (b) 
is  true,  then  every  state  S  in  which  the  available  units 
(r)  is  large  enough  will  be  a  safe  state.  If  r  is  larger 
that  the  sums  of  the  absolute  values  of  all  instructions 
for  all  nodes,  then  the  available  units  for  any  state  S* 
such  that  S  -*->  S’  will  be  strictly  positive.  Hence,  if 
5  -*->  S*  then  no  process  in  S*  can  be  deadlocked  (or  even 
blocked).  Therefore,  if  (a)  or  (b)  is  true,  then  the 
state  is  not  deadlocked. 

Lemma  6.1  is  no  longer  true  if  the  system  is  not 
restricted  to  have  both  a  single  type  of  resource  and  single 
unit  requests.  Figure  6.6  gives  an  example  of  a  system  which 
has  a  single  type  of  resource,  but  not  single  unit  requests. 
The  system  in  Figure  6.6  is  quite  similar  to  the  system  in 
Figure  6.5(c),  and  it  satisfies  neither  condition  (a)  nor  (b) 
of  Lemma  6.  1.  Thus,  one  is  tempted  to  conclude  that  the 
system  in  Figure  6.6  is  not  safe.  However,  as  the  reader  may 
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verify,  in  the  system  in  Figure  6.6,  every  state  except  state 
(  (Q 1  #Q4)  ,  (0) )  is  safe. 

The  results  given  in  Lemma  6.1  apply  to  a  subcase  of 
semaphore  systems  which  is  too  highly  restricted  to  be  of  much 
practical  value.  One  would  like  to  be  able  to  find  simple 
necessary  and  sufficient  conditions,  similar  to  those  given  in 
Lemma  6.1,  which  would  determine  if  an  arbitrary  semaphore 
system  were  safe  or  self  regulating.  Unfortunately,  no  such 
simple  conditions  have  been  found  by  the  author,  and  he  doubts 
that  they  exist.  Although  it  will  be  shown  in  Section  6.5 
that  it  is  decidable  if  an  arbitrary  semaphore  system  is  self 

the  decision  algorithm  is  neither  simple  nor  fast. 


regulating , 
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6.3  Semaphore  Systems  as  Claim  Limited  Systems 

In  this  section  we  establish  a  relationship  between 
semaphore  systems  and  claim  limited  consumable  resource 
systems.  This  relationship  is  important  for  two  reasons. 
First,  it  provides  us  with  simple  sufficient  conditions  (a) 
for  a  semaphore  system  to  be  safe  and  (b)  for  a  state  in  a 
semaphore  system  to  be  deadlocked.  Second,  it  shows  that 
claim  limited  consumable  resource  systems  are  good  models  for 
more  complex  systems  (semaphore  systems) . 

A  Sufficient  Condition  for  a  Safe  System 

tfe  will  say  that  process  Pi  in  a  semaphore  system 
"produces  resource  Rj"  if  some  instruction  in  the  process 
graph  for  Pi  increments  the  j-th  semaphore.  Similarly,  we 
will  say  that  process  Pi  "consumes  resource  R  j"  if  some 
instruction  in  the  process  graph  for  Pi  decrements  the  j-th 
semaphore.  A  semaphore  system  and  its  corresponding  claim 
limited  system  will  have  the  same  processes  and  resources,  and 
the  same  "producers”  and  "consumers”. 

Proceeding  formally,  we  define  a  mapping  CIS  from 
semaphore  systems  into  claim  limited  consumable  resource 
systems  as  follows: 

Let  S3  be  an  n  by  m  semaphore  system.  The  processes  and 
resources  of  claim  limited  consumable  resource  system 
CLS(SS)  are  {P 1 ,  P2,  .  .  .  ,  Pn)  and  {R  1 ,  R  2,  .  .  .  ,  Rm}  .  In 
CLS  (SS)  ,  process  Pi  is  one  of  the  producers  of  resource  Rj 
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if  and  only  if  there  is  a  node  with  instruction  I  = 
(1 1 , 12,-.  .  , Ira)  in  process  graph  Pi  of  SS  such  that  Ij  >  0. 
Similarly ,  in  CLS(SS)  process  Pi  is  one  of  the  consumers 
or  resource  Rj  if  and  only  if  there  is  a  node  with 
instruction  I  =  (1 1 , 12, . . . , Im)  in  process  graph  Pi  of  SS 
such  that  Ij  <  0. 

In  Figure  6.7  is  shown  the  claim  limited  consumable  resource 
graph  which  corresponds  to  the  semaphore  system  shown  in 
Figure  6.2. 

The  two  theorems  we  prove  in  this  section  will  result 
from  the  fact  that  the  claim  limited  system  corresponding  to  a 
semaphore  system  can  '‘mimic”  all  the  operations  (and  more)  of 
the  semaphore  system.  That  is,  any  incrementing  or 
decrementing  of  the  j-th  semaphore  which  can  be  accomplished 
by  process  Pi  in  the  semaphore  system,  can  also  be 
accomplished  by  process  Pi  in  the  claim  limited  system. 

Theorem _ 6_. J  Let  SS  be  a  semaphore  system.  If  claim 

i 

limited  consumable  resource  system  CLS  (SS)  is  safe,  then 
SS  is  safe  and  SS  is  not  self  regulating. 

Proof  From  Theorem  4.4,  if  CLS  (SS)  is  safe  then  its  claim 
limited  graph,  call  it  CLG,  is  completely  reducible.  Let 
the  numbers  of  the  processes  in  the  sequence  which 
completely  reduces  CLG  be  ( j 1 # j2 , . . . , jn)  .  The  theorem 
will  be  proved  by  showing  that  from  any  state  in  SS  there 
exists  a  sequence  of  operations  by  process  jl,  then  by 
process  j2 ,  ...,  and  then  by  jn,  leaving  every  element  in 
the  available  units  vector  arbitrarily  large.  Process  jl 
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can  never  be  blocked  in  SS  (or  in  CLS  (SS) )  because  jl 
consumes  no  resources.  (If  jl  were  a  consumer  of  one  or 
more  resources,  then  CLG  could  not  be  reduced  by  jl.)  In 
SS  let  process  jl  change  state  S  to  state  Si  by  executing 
operations  until  the  available  units  of  all  resources 
produced  by  jl  are  “large'1.  By  “large”  we  mean  large 
compared  with  the  number  of  operations  to  be  executed  by 
j2,j3,...,jn  as  will  be  described.  Process  j2  can  not  be 
blocked  in  state  Si  because  j2  consumes  only  resources 
produced  by  process  jl.  (If  j2  were  a  consumer  of 
resources  not  produced  by  jl,  then  CLG  could  not  be 
reduced  by  jl  and  then  by  j 2 . )  In  SS  let  process  j2 
change  state  SI  to  state  S2  by  executing  operations  until 
the  available  units  of  all  resources  produced  by  j2  are 
“large”.  By  “large”  we  mean  large  compared  with  the 
number  of  instructions  to  be  executed  by  j 3, j4, . . . , jn. 
Continuing  in  this  manner,  operations  by  j1,j2,...,jn  can 
change  the  system  state  from  S  to  Si  to  S2  ...  to  Sn  where 
no  process  will  be  blocked  in  Sn.  Therefore,  for  an 
arbitrary  state  S  in  SS,  no  process  is  deadlocked,  and  the 
available  units  can  be  made  arbitrarily  large.  Hence,  if 
CLS  (SS)  is  safe,  then  SS  is  safe  but  not  self  regulating. 

There  is  a  fast  algorithm  to  determine  if  the  claim 
limited  graph  for  a  claim  limited  consumable  resource  system 
is  completely  reducible  (see  Section  4.5).  Hence  for 
semaphore  system  SS,  there  is  a  fast  method  of  determining  if 
CLS ( SS)  is  safe.  If  CLS  (SS)  is  safe,  then  by  Theorem  6.1,  SS 
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must  also  be  safe.  However,  even  if  CLS  (SS)  is  not  safe,  SS 
may  still  be  safe.  For  example,  let  SS  be  the  semaphore 
system  shown  in  Figure  6.2.  It  can  easily  be  shown  that  SS  is 
safe.  However,  CLS  (SS)  is  not  safe  because  its  claim  limited 
graph,  as  shown  in  Figure  6.7,  is  not  completely  reducible. 

A  Sufficient  Condition  for  Deadlock 

We  have  shown  how  to  construct  a  claim  limited  consumable 
resource  system  which  can  "mimic"  the  behavior  of  a  semaphore 
system.  We  will  now  show  how  to  construct  for  each  state  in  a 
semaphore  system  a  corresponding  state  (a  consumable  resource 
graph)  in  a  claim  limited  system.  The  request  edges  in  the 
consumable  resource  graph  will  be  determined  by  the  next 
instructions  in  the  process  graphs  of  the  semaphore  system. 

Proceeding  formally,  we  define  a  mapping  CRG  from  the 
states  in  semaphore  system  SS  into  the  states  in  claim  limited 
consumable  resource  system  CLS(SS)  as  follows: 

let  S  be  a  state  in  SS  where  S  =  (  (Q1 ,... ,Qi, .. . ,Qn)  ,r) . 
CRG(S)  is  a  consumable  resource  graph  in  system  CLS  (SS) . 
The  available  units  vector  for  CRG(S)  is  r.  In  CRG  (S) 
there  are  request  edges  directed  from  node  Pi  if  and  only 
if  node  Ci  has  only  son  Qi«  whose  instruction  I  = 
(1 1 , 12, -. - ,Im)  is  a  reguest.  The  number  of  edges  directed 
from  node  Pi  to  resource  node  Rj  is  either  ~ I j  when  Ij  <  0 
or  zero  when  Ij  >  0. 

This  definition  of  CRG  (S)  does  not  explicitly  describe  the 
producer  edges  because  these  edges  are  the  same  for  all  states 
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in  system  CLS(SS),  and  these  edges  were  described  in  the 
definition  of  CLS(SS).  It  follows  easily  from  the  definition 
of  mapping  CRG  that: 

Process  Pi  is  blocked  in  state  S  of  system  SS  if  and  only 
if  process  Pi  is  blocked  in  state  CRG(S)  of  system 
CLS  (SS)  . 

Thus,  exactly  the  same  processes  are  blocked  in  S  and  CRG  (S) . 

We  now  show  that  if  we  detect  that  CRG  (S)  is  a  deadlock 
state,  then  it  must  be  that  S  is  also  a  deadlock  state. 

Theorem _ 6_.2  Let  S  be  a  state  in  semaphore  system  SS.  If 

CRG  (S)  is  a  deadlock  state  in  CLS  (SS) ,  then  S  is  a 
deadlock  state  in  SS. 

Proof  The  proof  will  depend  upon  the  proposition:  if  for 
some  i w  S  -i->  S»,  then  CRG  (S)  -*->  CRG  (S’).  First  we 

will  prove  the  proposition.  Let  S  =  (  (Q 1 , .  .  .  ,  Qn)  ,  r)  and 
let  S'  =  (  (Q1 * , •• . ,Qn * ) , r •) •  Let  Qi ”  be  a  son  of  Qi*. 

Let  the  instructions  for  Qi*  and  QiH  be  I  =  (I1,...,Im) 
and  J  -  (Jl,...,Jm).  Given  that  S  -i->  S*,  the  following 
operations  in  system  CLS(SS)  change  state  CRG(S)  to 
CRG  (S')  . 

First  ,  if  I  is  a  request  instruction,  then  there  is  an 
acquisition  by  Pi  of  -Ik  units  of  each  resource  Rk 
such  that  Ik  <  0. 

Next ,  if  for  some  j,  Ij  >  0,  then  there  is  a  release 
by  Pi  of  Ik  units  of  each  resource  Rk  such  that  Ik  > 

0. 

Finally,  if  J  is  a  request  instruction,  then  there  is 
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a  request  by  Pi  for  -Jk  units  of  each  resource  Rk  such 
that  Jk  <  0. 

The  state  resulting  from  these  operations  is  easily  shown 
to  be  CRG  (S').  Therefore,  if  for  some  i,  S  -i->  S'  then 

CRG(S)  - *->  CRG(S'),  By  extension,  if  S  -*->  S'  then 
CRG  (S)  -*->  C8G  (S') . 

Now  we  will  prove  Theorem  6.2  by  showing  that  if  S  is 
not  a  deadlock  state,  then  CRG  (S)  is  not  a  deadlock  state. 
If  S  is  not  a  deadlock  state,  then  for  any  process  Pi,  S 
-*->  S'  where  Pi  is  not  blocked  in  S*.  Hence,  CRG(S)  -*-> 
CRG  (S').  Recall  that  Pi  is  blocked  in  S'  if  and  only  if 
Pi  is  blocked  in  CRG(S').  Since  for  any  process  Pi, 
CRG  (S)  -*->  CRG  (S' )  where  Pi  is  not  blocked  in  CRG(S'), 
then  CRG  (S)  is  not  a  deadlock  state.  Therefore,  if  S  is 
not  a  deadlock  state,  CRG  (S)  is  not  a  deadlock  state. 

In  Figure  6.8  is  shown  the  consumable  resource  graph  which 
corresponds  to  state  ( (p3 fc5)  ,  (0,0) )  in  the  semaphore  system 
of  Figure  6.2.  The  consumable  resource  graph  is  Figure  6.8  is 
completely  reducible,  and  thus,  is  not  a  deadlock  state. 
Therefore,  we  know  that  state  {  (p3 ,c5) ,  (0,0) )  in  the  semaphore 
system  is  not  a  deadlock  state. 

We  may  interpret  that  a  claim  limited  system  which  models 
a  semaphore  system  "throws  away"  enough  information  from  the 
semaphore  system  to  make  detection  of  deadlock  and  safeness 
easy.  At  the  same  time,  the  claim  limited  system  retains 
enough  information  so  that  deadlock  and  safeness  in  the  claim 
limited  system  are  still  sufficient  conditions  for  deadlock 
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and  safeness  in  the 
limited  system  uses 
process  (the  sets  of 
process)  to  determin 


semaphore  system.  In  short,  the  claim 
only  the  "external  properties"  of  each 
resources  produced  and  consumed  by  each 
e  the  deadlock  properties  of  the  more 


complex  system  (the  semaphore  system) . 
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PI  (Producer) 


Figure _ Jy.7  The  clai 

corresponds  to  the 
semaphore  system  is 
completely  reducible. 


m  limited  consumable  resource  graph  which 
semaphore  system  in  Figure  6.2.  The 
safe  even  though  this  graph  is  not 


PI  (Producer) 


Figure _ 6^8  The  consumable  resource  graph  corresponding  to 

state  (  (p3 , c5)  ,  (0 , 0) )  in  the  semaphore  system  of  Figure  6.2. 
Since  the  consumable  resource  graph  is  not  a  deadlock  state, 
then  (  (p3, c5) ,  (0 , 0) )  is  not  a  deadlock  state. 
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6.4  Vector  Addition  Systems 

In  Section  6.3  it  was  shown  how  to  construct  a  claim 
limited  system  corresponding  to  each  semaphore  system;  the 
claim  limited  system  is  used  to  determine  deadlock  properties 
of  the  semaphore  system.  In  a  similar  manner,  in  Section  6.5, 
we  will  show  how  to  construct  a  “vector  addition  system" 
corresponding  to  each  semaphore  system;  the  vector  addition 
system  is  used  to  determine  deadlock  properties  of  the 
semaphore  system.  In  the  present  section  we  will  define 
vector  addition  systems  and  give  known  results  about  them. 

Vector  addition  systems  are  abstract  mathematical 
structures.  We  quote  Karp  and  Miller  [ pg.  1 65,  1 969  ],  "These 
structures  are  of  independent  interest,  and,  in  addition  to 
their  relevance  to  program  schemata,  arise  from  such  subjects 
as  the  word  problem  for  commutative  semigroups  (this 
connection  has  been  explored  by  M.  Eabin) ,  the  theory  of 
bounded  context  free  languages,  and  the  theory  of  uniform 
recurrence  equations."  Our  interest  in  these  structures 
results  from  their  ability  to  "mimic"  semaphore  systems. 

We  define  these  structures  as  follows: 

An  x  ky  y  vector  addition  system  (or  simply,  a  vector 


addition  system)  is 


nonempty  set  of  nonzero 


y-dimensional  integer  vectors  { V 1 , V2 , . . . , Vx} . 

The  set  of  states  SIGMA  of  an  x  by  y  vector  addition  system  is 
the  set  of  all  nonnegative  y-dimensional  vectors. 

Corresponding  to  each  vector  Vi  in  a  vector  addition 
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system  is  a  process  Pi.  We  will  define  process  Pi  by 
describing  Its  operations.  If  s  and  T  are  states  in  the 
vector  addition  system,  and  S+Vi  =  T  >  0,  then 

S  -i~>  T. 

From  this  description  of  operations  in  a  vector  addition 
system,  and  from  the  definition  of  "blocked’'  in  Section  2.2, 
it  follows  that: 

Process  Pi  is  blocked  in  state  S  of  a  vector  addition 
system  if  and  only  if  for  some  j,  sj  +  Vij  <  0  where  S  - 
(SI  ,S2,..  .  ,Sy)  and  Vi  =  ( Vi  1 ,  Vi2 , .  .  .  ,  Viy)  . 

This  is  equivalent  to  the  proposition  that  process  Pi  is  not 
blocked  in  state  S  if  and  only  if  S  +  Vi  >  0. 


Interpretations  of  Vector  Addition  Systems 

We  will  now  give  five  ways  of  interpreting  vector 
addition  systems.  These  interpretations  are  further  evidence 
that  vector  addition  systems  are  of  "independent  interest". 

i 

1.  Simple  Semaphore  Systems.  We  define  a  "simple 
semaphore  system"  as  a  semaphore  system  in  which  all  process 
graphs  have  exactly  one  node.  Figure  6.9(a)  shows  an  example 
of  a  simple  semaphore  system.  The  reader  may  verify  that  this 
system  is  self  regulating.  Since  there  is  only  one  node  in 
each  process  graph,  the  process  node  vector  is  the  same  for 
all  states  in  a  simple  semaphore  system.  Hence,  we  can 
represent  a  system  state  unambiguously  by  simply  giving  its 
available  units  vector.  Once  we  represent  the  states  by  their 
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available  units  vectors,  the  operations  of  the  simple 
semaphore  system  in  Figure  6.9(a)  become  identical  to  the 
operations  of  the  vector  addition  system  {V1,V2>  where  VI  = 
(2, -4, -3, 4)  and  V2  =  (-2, 4, 3,-4).  In  general,  every  simple 
semaphore  system  is  isomorphic  to  a  vector  addition  system. 

The  only  reason  that  every  vector  addition  system  is  not 
isomorphic  to  a  simple  semaphore  system  is  that  the  definition 
of  semaphore  systems  includes  the  requirement  that  at  least 
one  instruction  must  increment  and  decrement  each  semaphore. 
If  we  relax  this  requirement  for  simple  semaphore  systems, 
then  simple  semaphore  systems  and  vector  addition  systems  are 
two  equivalent  interpretations  of  the  same  mathematical 
structure. 

2.  A  Graph  Model .  We  can  represent  an  x  by  y  vector 
addition  system  by  a  graph  model  which  is  similar  in 
appearance  to  a  consumable  resource  graph.  The  graph  model  is 
a  bipartite  directed  graph  in  which  the  disjoint  subsets  of 
nodes  are  { P 1 , P2 , Px)  and  {R 1 , R2,  .  .  .  ,  Ry }  „  Let  the  vector 
addition  system  be  {V 1 , V2, . . - , Vx)  and  let  Vi  = 
{Vi  1 , Vi 2, . . . , Viy) .  In  the  directed  graph  there  is  an  edge 
directed  from  node  Pi  to  node  Rj  if  and  only  if  Vij  <  0;  if 
such  an  edge  exists,  it  is  labelled  -Vij.  There  is  an  edge 
directed  from  node  Rj  to  Pi  if  and  only  if  Vij  >  0;  if  such  an 
edge  exists,  it  is  labelled  Vij. 

In  Figure  6.9(b)  we  illustrate  the  graph  model  of  the 
vector  addition  system  {VI, V2]  where  VI  =  (2, -4, -3, 4)  and  V2  - 
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{”2,4,3,  4)  .  As  can  be  seen  in  the  figure,  the  edges  directed 
to  and  from  a  process  node,  say  PI,  uniguely  determine  the 
corresponding  vector  {VI).  The  state  of  the  system  in  the 
figure  is  (4, 4, 3,3).  This  is  shown  by  drawing  4  subnodes 
inside  81,  4  subnodes  inside  R2,  3  subnodes  inside  R3,  and  3 

subnodes  inside  R4. 

(if  ”  1  -  Vij  <  *1  for  all  i  and  j,  then  this  graph  model 
becomes  equivalent  to  a  Petri  net  [Holt,  AM  1968].) 

Me  may  interpret  that  the  processes  in  the  graph  model 
are  " transducers".  For  example,  process  PI  can  "transduce"  4 
units  of  resource  R2  and  3  units  of  resource  R3  into  2  units 
of  R 1  and  4  units  of  R4. 

3.  Ecological  Systems.  Animals  consume  oxygen  and  starch 
and  produce  carbon  dioxide  and  water  vapor.  Plants  consume 
carbon  dioxide  and  water  and  produce  oxygen  and  starch.  The 
simplified  chemical  equations  for  these  simplistic  ecological 
observations  are  as  follows: 

t 

Animals:  4  CHO  +  3  02  — >  2  H20  +  4  C02 
Plants:  2  H20  ♦  4  C02  — >  4  CHO  +  3  02 
Me  may  think  of  plants  and  animals  as  "transducers”.  For 
example,  an  animal  can  "transduce"  4  molecules  of  CHO  and  3 
molecules  of  02  into  2  molecules  of  H20  and  4  molecules  of 
C02. 

It  has  purposely  been  arranged  so  that  this  ecological 
system  is  isomorphic  to  the  previous  examples  of  simple 
semaphore  systems  and  graph  models.  H20,  CHO,  02,  and  C02  are 
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equivalent  to  R1,  R2,  R3,  and  F4,  respectively;  animals  and 
plants  are  equivalent  to  PI  and  P2,  respectively. 

Given  that  the  only  interactions  in  our  environment  are 
those  represented  by  the  above  two  chemical  equations,  it 
follows  that  our  environment  is  both  ’'safe”  and  "self 
regulating" . 

Of  course,  the  interactions  of  our  environment  are 
actually  vastly  more  complex  than  these  two  equations,  and  it 
is  not  particularly  obvious  whether  the  environment  is  either 
"safe"  or  "self  regulating".  Indeed,  it  seems  quite  important 
to  be  able  to  determine  which  species  ("processes")  are  safe 
from  extinction  ("deadlock").  It  is  also  important  to  know 
which  resources  may  grow  without  bound,  and  thus  may  "pollute" 
the  environment. 

The  point  is  that  vector  addition  systems  may  be 
interpreted  as  interacting  species  in  an  environment,  i.e.,  as 
ecological  systems. 


4.  A  Carnival  Game^  We  will  describe  a  gam 
somewhat  similar  to  the  classical  game  of  "tower 
[pg.97,  Griswold  1968].  The  game  is  played  with  a 
which  project  y  vertical  posts.  For  purposes  of  ex 
we  will  let  y  =  4,  and  we  will  name  the  posts  R1,  R 


R  4 


There  are  a  large  number  of  identical  "disks" 


which  fit  onto  the  posts.  The  carnival  entrepreneur 
initial  number  of  disks  on  each  pole  and  invent 


rules  by  which  the  player  is  allowed  to  manipulate 


e  which  is 
of  Hanoi" 
board  from 
planation, 
2,  R3,  and 
or  "beads" 
puts  some 
s  a  set  of 
the  disks. 
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Each  rale  is  of  the  form  ( v  1,  v2,  v3,  v4)  where  vj  gives  the 
number  of  disks  to  be  placed  on  pole  Rj;  for  example,  the  rule 
(2,-4, -3, 4)  allows  the  player  to  put  two  disks  on  Hi,  remove  4 
disks  from  R2,  remove  3  disks  from  R3,  and  put  4  disks  on  R4. 
The  whole  rule  must  be  applied  at  once  and  thus,  the  rule 
(2#”4,— 3,4)  can  not  be  used  unless  there  are  at  least  4  disks 
on  R2  and  at  least  3  disks  on  B3.  See  Figure  6.9(c)  for  an 
example  of  this  game.  The  player  wins  if  he  can  jam 
("dead lock”)  the  game,  i.e. ,  he  wins  if  he  can  manipulate  the 
disks  (using  the  given  rules)  to  a  configuration  in  which  some 
rule  can  never  be  used  again.  In  the  game  in  Figure  6.9(c) 
the  player  can  not  possibly  win  because  the  initial  state  of 
the  game  is  "safe". 

5.  Mult i-dimensicnal  Chess.  We  can  consider  that  a 
vector  addition  system  defines  the  rules  by  which  a  chess  man 
can  move  in  y-dimensional  chess.  For  example  in  conventional 
2-dimensional  chess,  the  vector  addition  system  for  the  knight 
is  {(2,1),  (2,-1),  (-2,1),  (-2,-1),  (1,2),  (1,-2),  (-1,2), 
(-1,-2)}.  As  we  have  defined  vector  addition  systems,  the 
"chessboard"  for  the  2-dimensional  case  will  have  only  two 
edges,  and  will  stretch  off  to  infinity  in  two  directions. 
For  the  general  case  of  more  that  2  dimensions,  an  x  by  y 
vector  addition  system  can  be  thought  of  as  a  set  of  x  rules 
for  moving  a  chess  man  about  on  a  y-dimensional  chess  board. 


Known  Results  for  Vector  Addition  Systems 
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We  give  several  results  for  vector  addition  systems  which 
have  been  developed  or  guoted  by  Karp  and  Miller 
[ pp. 16 5- 1 69 , 1  969  ].  Most  of  these  results  are  derived  from  the 
"reachability  tree"  associated  with  each  state  in  a  vector 
addition  system.  First  we  define  a  "tree": 

A  tree  is  a  directed  graph  such  that  exactly  one  node 
(called  the  root]_  is  a  source,  all  other  nodes  have 
exactly  one  father,  and  there  is  a  path  directed  from  the 
root  to  any  other  node. 

We  will  define  the  reachability  tree  of  state  S,  written 
RT  (S) ,  by  giving  a  recursive  procedure  for  generating  RT(S). 
RT (S)  is  a  tree  which  has  a  label  L(a)  associated  with  each 
node  a.  1(a)  is  a  y-dimensional  vector  whose  elements  are 
either  nonnegative  integers  or  OMEGA.  (OMEGA  was  defined  in 
Section  4.2.)  The  rules  for  generating  RT  (S)  are  as  follows: 

(1)  The  label  of  the  root  is  S. 

(2)  Let  b  be  a  node  in  the  tree.  If  there  is  node  a  in 
*  the  tree  such  that  L(a)  =  1(b)  and  there  is  a  path 

directed  from  a  to  b,  then  b  is  a  sink;  otherwise,  there 
is  a  son  of  b  for  each  i,  1  <  i  <  x,  such  that  1(b)  +  Vi  > 
0.  Let  the  son  corresponding  to  i  be  si.  The  j-th 
element  of  label  L  (si)  is  determined  as  follows: 

(a)  If  there  exists  node  c  in  the  tree  such  that  a 
path  is  directed  from  c  to  si  and  L (c)  <  L (b)  ♦  Vi  and 
the  j-th  element  of  L (c)  is  less  than  the  j-th  element 
of  L(b)  +  Vi,  then  the  j-th  element  of  L(si)  is  OMEGA. 

(b)  If  no  such  node  c  exists  then  the  j-th  element  of 
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L  (si)  is  the  j-th  element  of  I  (b)  +  Vi. 

See  Figure  6.10  for  an  example  of  a  reachability  tree. 

Karp  and  Miller  have  proved  that  a  reachability  tree  is 
necessarily  finite  [ pg.  1 66,  1 969  ]. 

6-.-  a  vector  addition  system,  for  a  given  state 
U#  there  exists  some  state  T  in  RS  (S)  such  that  T  >  0  if 
and  only  if  there  exists  node  a  in  RT(S)  such  that  L (a)  > 

U. 

The  proof  Theorem  6.3  is  omitted  because  it  has  been  given  by 
Karp  and  Miller  [1969]  and  repeated  by  Slutz  [1968], 

Corollary  6^2  in  a  vector  addition  system, 

(1)  It  is  decidable  for  given  state  U  if  there  exists  T, 
T  >  U,  such  that  S  -*->  T; 

<2)  it  is  decidable  if  RS  {S)  is  finite. 

(1)  follows  immediately  from  Theorem  6.3  and  the 
fact  that  RT  (S)  is  finite  and  constr uctable.  From  Theorem 
6.3  it  fellows  that  RS{S)  is  finite  if  and  only  if  OMEGA 
does  not  appear  in  a  label  in  RT  (S) . 

Theorem  6 J  For  vector  addition  systems  V  and  W  it  is  not 
decidable  if  RS(S,V)  =  RS  (T,W). 

Theorem  6.4  is  an  unpublished  result  by  M.  Rabin  which  is 
quoted  by  Karp  and  Miller  [1969]. 

There  is  an  obvious  and  innocent  appearing  open  question 
about  vector  additions  systems: 

Conjjectujre  6,  1  In  a  vector  addition  system  it  is  not 

decidable  if  S  -*->  T. 

This  question  (whether  Conjecture  6. 1  is  true)  has  been  known 


SECTION  6.4  217 


to  J.  Hopcroft  and  M.  Rabin  since  about  1966,  and  it  remains 
open  despite  the  efforts  of  a  number  of  researchers  to  answer 
it. 

Deadlock  Properties  of  Vector  Addition  Systems 

Using  Corollary  6.1,  we  can  show  that  two  of  the  most 
important  questions  about  deadlock  in  vector  additions  systems 
are  decidable: 

Theorem  6_.5  In  a  vector  addition  system, 

(1)  it  is  decidable  if  a  state  is  a  deadlock  state,  and 

(2)  it  is  decidable  if  a  state  is  self  regulating. 

Proof  First  we  prove  (1).  Process  Pi  is  not  blocked  in 
state  T  if  and  only  if  T  +  Vi  >  0.  Thus,  process  Pi  is  not 
deadlocked  in  S  if  and  only  if  S  —  *->  T  where  T+Vi  >  0. 
Let  Vi  =  (Vi  1 , Vi2#. . . , Viy) .  Let  us  define  U  = 
(U  1  , U2 , . -  -  , Uy)  such  that  Uj  =  0  if  Vij  >  0  and  Dj  =  -Vij 

if  Vij  <  0-  To  decide  if  Pi  is  deadlocked  in  S,  one  has 

only  to  decide  if  there  exists  T  >  U  such  that  S  -♦->  T. 


3y  Corollary 

6.1  {1 )  ,  this 

question  is 

decidable,  and 

therefore  it  is 

decidable  if 

Pi  is  deadlocked  in  S. 

Since 

it  is  decidable  for  any 

process  Pi 

whether 

Pi  is 

deadlocked  in 

S,  then  it 

is  decidable 

whether 

S  is  a 

deadlock  state. 

Now  we  prove  (2) .  State  S  is  self  regulating  if  and 
only  if  RS  (S)  is  finite  and  for  all  T  in  RS  (S) ,  T  is  not  a 
deadlock  state.  By  Corollary  6.1(2)  it  is  decidable  if 
SS { S)  is  finite.  When  RS{S)  is  finite,  every  state  T  in 
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RS  (S)  can  be  generated*  By  Theorem  6*5(1)  it  is  decidable 
for  each  state  T  in  RS(T)  whether  T  is  a  deadlock  state. 
Hence,  it  is  decidable  if  S  is  a  self  regulating  state. 
Unfortunately,  there  does  not  seem  to  be  a  way  to  use 
Corollary  6.1  to  determine  if  a  state  is  safe,  and  we  are  left 
with  the  unproven  conjecture: 

Conjecture  6.2  In  a  vector  addition  system  it  is  not 
decidable  if  a  state  is  safe. 

This  conjecture  seems  to  be  closely  related  to  Conjecture  6.1; 
hopefully,  a  proof  (or  disproof)  of  one  conjecture  will  lead 
to  a  proof  (or  disproof)  of  the  other. 

Our  knowledge  about  the  deadlock  properties  of  vector 
addition  systems  can  be  paraphrased  in  terms  of  the  "carnival 
game"  interpretation  of  vector  additions  systems.  We  can  tell 
if  the  player  has  won  the  game,  because  we  can  decide  if  the 
game  is  "deadlocked”.  However,  we  do  not  know  of  any  analysis 
the  player  can  do  before  starting  the  game  in  order  to 

i 

determine  if  it  is  possible  for  him  to  win;  that  is,  we  do  not 
know  of  an  algorithm  which  determines  if  the  game  is  "safe". 
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(a)  A  simple  semaphore  system. 


PI 


R4 


(b)  A  graph  iacdel  of  a  vector  addition  system, 
of  the  system  is  S  =  (**,4,3,3). 


The  state 


(c)  A  carnival  game.  The  player  can  use  two  rules: 

CD  he  can  remove  4  disks  from  R2  and  3  disks  from  R3 

and  put  2  disks  on  R1  and  4  disks  on  HU,  or 

(2)  he  can  remove  2  disks  from  El  and  4  disks  from  R2 

and  put  4  disks  on  E2  and  3  disks  on  R3. 

The  player  wins  when  he  manipulates  the  disks  so  that 
he  can  never  again  use  one  of  the  rules.  (He  loses  this 
game.) 


Figure _ 6^9  Seme  interpretations  of  the  vector  addition  system 

{V1,V2}  where  VI  =  (2, -4, -3,4)  and  V2  =  (-2,4, 3, -4). 
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Figure _ 6.  1 0  The  reachability  tree  for  state  S  -  (1,0,0)  in 

vector  addition  system  {(-1,1,0),  ("1*0/0)#  (0,-1, 2), 


(0,  1,-1)}. 
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6.5  Semaphore  Systems  as  Vector  Addition  Systems 

In  this  section  we  give  a  method  of  constructing  a  vector 
addition  system  for  each  semaphore  system.  The  vector 
addition  system  will  "mimic”  the  operations  of  the  semaphore 
system,  and  will  be  used  to  determine  if  a  state  in  the 
semaphore  system  is  deadlocked  or  self  regulating. 

Standard  Semaphore  Systems 

First  we  will  show  how  to  change  a  semaphore  system  into 
a  "standard  form”,  and  then  we  will  give  a  simple  mapping  of 
"standard”  semaphore  systems  into  vector  addition  systems. 
Let  us  define  a  "standard"  directed  graph: 

A  standard  directed  graph  is  a  directed  graph  with  the 
property  that  for  every  edge  <Qi,Qj) ,  Qi  *  Qj  and  one  or 
both  of  the  following  are  true: 

(1)  node  Qi  has  only  one  son,  Qj, 

(2)  node  Qj  has  only  one  father,  Qi. 

We  partition  the  set  of  edges  of  a  standard  directed  graph 
into  disjoint  subsets  called  connections  in  the  following 
manner : 

Edges  (Q i , Q j )  and  (Qu,Qv)  are  in  the  same  connection  if 
and  only  if  Qi  =  Qu  or  Qj  =  Qv. 

If  connection  C  contains  edge  (Qi,Qj) ,  then  we  will  say  that 
connection  C  is  a  son  of  Qi  and  that  connection  C  is  a  father 
of  node  Qj.  It  follows  that: 
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In  a  strongly  connected  standard  directed  graph,  for  a 
given  node  Qi,  exactly  one  connection  is  a  father  of  Qi 
and  exactly  one  connection  is  a  son  of  Qi. 

A  "standard”  semaphore  system  is  defined  as  follows: 

^  process  graph  is  a  process  graph  whose  directed 

graph  is  standard.  A  standard  semaphore  system  is  a 
semaphore  system  all  of  whose  process  graphs  are  standard. 
We  now  give  a  method  for  transforming  a  process  graph  into  an 
equivalent  standard  process  graph.  For  every  edge  (Qi,Q-j)  in 
the  graph  such  that  Qi  •=  Q j  or  such  that  Qi  has  more  than  one 
son  and  Qj  has  more  than  one  father: 

A  new  node  Qv  whose  instruction  is  null  is  added  to  the 
graph,  edge  (Qi,Qj)  is  deleted,  and  edges  (Qi,Q v)  and 
(Qv,Qj)  are  added  to  the  graph. 

Intuitively,  this  means  that  whenever  an  edge  (Qi,Qj)  violates 
the  requirements  for  a  standard  graph,  it  is  replaced  by  path 
(Qi,Qv,Q j)  where  the  instruction  for  Qv  does  nothing. 

i 

By  transforming  each  process  graph  in  a  semaphore  system 
into  a  standard  process  graph,  one  can  transform  any  semaphore 
system  into  a  standard  semaphore  system.  Without  giving  a 
proof,  we  assert  that  state  S  in  the  original  semaphore  system 
will  be  deadlocked,  safe,  or  self  regulating  if  and  only  if 
state  S  is  deadlocked,  safe  or  or  self  regulating  in  the 
transformed  system. 
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Encoding  a  Semaphore  System  as  a  Vector  Addition  System 

We  associate  with  each  standard  semaphore  system  a  vector 
addition  system.  Each  vector  in  the  vector  addition  system 
corresponds  tc  a  node  in  a  process  graph.  Essentially,  the 
processes  in  the  standard  semaphore  system  are  subdivided  into 
smaller  processes  (vectors) ,  one  small  process  for  each  node 
in  the  original  process  graphs.  In  the  vector  addition  system 
there  is  a  counter  for  each  semaphore  in  the  semaphore  system. 
In  addition,  in  the  vector  addition  system,  there  is  a  counter 
for  each  connection  in  the  process  graphs;  the  counters  for 
the  connections  will  assume  only  the  values  0  and  1  and  will 
be  used  to  indicate  which  instructions  in  the  process  graphs 
have  just  been  executed. 

Proceeding  more  formally,  we  define  a  mapping  VAS  from 
standard  semaphore  systems  into  vector  addition  systems  as 
follows: 


Let  SS 

be 

an  n 

by  m  standard 

semaphore  system.  In  SS 

suppose 

that 

the 

total  number 

of  nodes  in 

the  process 

graphs 

is  q 

and 

that  the  nodes 

are  called  QI 

, Q2, . . . , Qq. 

Further , 

in 

SS 

suppose  that 

the  total 

number  of 

connections  in  the  process  graphs  is  c  and  that  the 
connections  are  called  C 1 ,C2 , . . . ,Cc.  VAS(SS)  is  an  x  by  y 
vector  addition  system  {VI , V2 ,. . . , Vx]  in  which  x=g  and 
y=ra+c.  Suppose  the  instruction  for  node  Qi  is 
1=  (1 1 , 12, . . . # Ira) ,  and  that  Cf  and  Cs  are  the  connections 
which  are  the  father  and  son,  respectively,  of  node  Qi. 
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Then 


the 


i-th 


vector 


in 


VAS  (SS) 


is 


Vi=  (1 1  #  12 


Im , L 1 , L2 


r  •  *  • 


,lc)  where  Lf=-1,  Ls=+1,  and 


Lk=0  for  k#f  and  k#s. 

We  define  a  mapping  VASS  from  the  states  in  SS  into  the 
states  of  VAS(SS)  as  follows: 


Suppose  S=  (  (Q 1 


rQn) ,  (r1,r2 


rm) ) .  Then 


VASs  (S )  -  { r  1 , r 2, . . . , r m# L 1 , L2 , . . . , Lc)  where  if  for  some  i, 
1<i<nr  node  Qi  is  a  father  of  connection  Cj  then  Lj=1, 
otherwise  Lj=0. 

Notice  that  in  VASS(S)  exactly  n  of  the  Lj  will  be  1 ,  and  the 
rest  of  the  Lj  will  be  0. 

Figure  6.11  gives  the  graph  model  of  the  vector  addition 
system  for  the  semaphore  system  in  Figure  6.2.  In  Figure  6.11 
there  is  a  resource  node  for  semaphores  n  and  F  plus  a 
resource  node  for  each  connection  in  the  semaphore  system. 
One  subnode  is  drawn  inside  the  resource  node  for  M.  One 
subnode  is  drawn  inside  the  resource  node  for  the  connection 

i 

between  nodes  pi  and  p2,  and  one  subnode  is  drawn  inside  the 
resource  node  for  the  connection  between  nodes  c5  and  cl.  No 
other  subnodes  are  drawn.  This  indicates  that  the  state  of 
the  vector  addition  system  corresponds  to  state 

( (pi *c5) #  (1 ,0) )  in  the  semaphore  system. 

Deadlock  Properties  of  Semaphore  Systems 

Since  semaphore  systems  can  be  encoded  as  vector  addition 
systems ,  the  properties  of  the  two  systems  are  essentially  the 


same. 
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Rabin* £  result  can  be  extended  to  show  that  for  semaphore 
systems  SS  and  SS*,  it  is  not  decidable  if 

RS  (S#SS) -RS  (S *  , SS * ) .  Given  that  Conjecture  6.1  is  true,  one 
can  prove  that  in  a  semaphore  system  it  is  not  decidable  if 
S  -*->  T. 

We  will  now  show  that  the  deadlock  properties  of 
semaphore  systems  and  vector  addition  systems  are  the  same. 
First,  in  Lemma  6.2  we  demonstrate  that  the  operations  in  a 
semaphore  system  and  in  its  corresponding  vector  addition 
system  are  essentially  the  same. 

Lemma  6. 2  Let  S  and  S*  be  states  in  standard  semaphore 
system  SS.  Let  S  *={  (Q 1  *,...,  Qi  *,...,  Qn  *),  r  *)  .  Let  Vj  be 
the  vector  in  VAS(SS)  which  corresponds  to  node  Qi*  in 
process  graph  Pi  of  SS. 

(1)  If  S  -i->  S*  in  SS,  then  VASS  (S)  -j->  VASS(S»)  in 
VAS  (SS) . 

(2)  If  S  -*->  S»  in  SS,  then  VASS  (S)  -*->  VASS{S*)  in 
•  VAS  (SS)  . 

(3)  If  VASS(S)  — j->  X,  then  there  exists  S*  such  that 
V  A  S  S  { S  * )  =  X  and  S  -i->  S*. 

(4)  If  VASS  (S)  -*->  X,  then  there  exists  S*  such  that 
VASS  (S ' ) — X  and  S  -*->  S*. 

Proof  The  proof  simply  verifies  that  the  vector  addition 
system  faithfully  mimics  the  semaphore  system.  We  give 
only  an  outline  of  the  proof. 

(1)  is  true  because  the  sum  of  the  available  units  in 
S  and  the  instruction  for  Qi*  is  nonnegative,  and  edge 
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(Qi,Qi»)  exists  in  process  graph  Pi,  (2)  follows  from 
applying  (1)  to  a  sequence  of  operations,  (3)  is  proved 
by  showing  (a)  process  graph  Pi  must  contain  edge 
(Qi,Qi*),  (b)  the  sum  of  the  available  units  of  S  and  the 
instruction  for  Qi«  is  nonnegative,  (c)  S  -*->  S»,  and  (d) 
VA5S(S’)=X,  (4)  follows  from  applying  (3)  to  a  sequence 

of  operations. 

Now  it  will  be  shown  that  a  state  in  a  semaphore  system  is 
safe  or  self  regulating  exactly  when  the  corresponding  state 
in  a  vector  addition  system  is  safe  or  self  regulating. 

Lemma  6,_3  Let  S  be  a  state  in  standard  semaphore  system 

ss. 

(1)  S  is  a  safe  state  in  SS  if  and  only  if  VASS(S)  is  a 
safe  state  in  VAS{SS), 

(2)  S  is  a  self  regulating  state  in  SS  if  and  only  if 
VASS(S)  is  a  self  regulating  state  in  VAS(SS). 

Proof  First  we  prove  that  if  VASS  (S)  is  a  safe  state,  then 
S  is  a  safe  state.  If  VASS (S)  is  safe,  then  process  Pi 
can  not  be  deadlocked  in  S  by  the  following  reasoning. 
For  any  vector  Vj  which  corresponds  to  a  node  in  process 
graph  Pi,  there  exists  X  such  that  VASS(S)  -*->  X  and  Pj 
is  not  blocked  in  X.  Thus,  S  -*->  S*  where  VASS (S') =X. 
Since  Pj  is  not  blocked  in  X=VASS(S') ,  then  Pi  is  not 
blocked  in  S*.  Thus,  an  arbitrary  process  Pi  in  S  is  not 
deadlocked,  and  hence,  S  is  not  a  deadlock  state.  Now  we 
show  that  if  S  -*->  S',  then  S*  is  not  a  deadlock  state. 
If  S  -*->  s»,  then  VASS  ( S)  -*->  VASS(S’)  and  since  VASS(S) 
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is  safe,  so  is  VASS(S*)-  The  fact  that  VAS S(S»)  is  safe 
implies  that  S*  is  not  a  deadlock  state  (just  as  the  fact 
that  VASS(S)  is  safe  implies  that  S  is  not  a  deadlock 
state).  Hence,  if  VASS  (S)  is  safe,  then  for  all  S*  such 
that  S  -*— >  s* ,  S*  is  not  a  deadlock  state,  i.e. ,  S  is 
safe. 

Next  we  prove  that  if  S  is  a  safe  state,  then  VASS(S) 
is  a  safe  state.  The  proof  will  follow  from  the 
observation  that  if  S  is  safe,  then  there  must  be  a 
sequence  of  operations  from  S  which  includes  the  execution 
of  any  particular  instruction  in  any  process  graph.  We 
first  show  that  if  S  is  safe  then  VASS(S)  is  not  a 
deadlock  state.  Let  Qi  be  the  i-th  node  of  the  process 
node  vector  for  S,  and  let  Qi*  be  any  node  in  process 
graph  Pi.  Since  process  graph  Pi  is  strongly  connected, 
there  is  a  path,  (Qi, q 1 , g2 ,. . . , a v, Qi • ) ,  directed  from  Qi 
to  Qi*.  We  will  show  that  if  S  is  safe  then  S  -*->  Si, 
Si  -  *->  S2,  . . . ,  Sv  -*->  T  where  the  i-th  elements  of  the 
process  node  vectors  for  S,S1 ,S2,.. . ,Sv  and  T  are  Qi,  qi, 
q2,  ...,  av,  and  Qi*,  respectively.  If  the  instruction 
for  gl  is  not  a  request  then  S  — i->  SI  because  (Qi,q1)  is 
an  edge  and  Pi  is  not  blocked  in  S.  If  the  instruction 
for  gl  is  a  request  then  (assuming  S  is  safe)  it  must  be 
that  a  sequence  of  operations,  which  does  not  include  an 
operation  by  Pi,  changes  S  to  S*  where  Pi  is  not  blocked 
in  S*.  Thus,  S  -*->  S*.  Then  S*  -i->  SI  where  qi  is  the 
i-th  element  of  the  process  node  vector  for  SI.  Hence,  if 
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S  is  safe  then  S  -*->  S'  and  S'  -i->  SI,  and  thus 
S  -*->  SI.  Similarly,  one  can  show  that  Si  -*->  S2, 

S2  -*->  S3,  - -  and  Sv  -*->  T,  and  that  Sv  -*->  T*  and 

T'  -i->  T  where  Qi'  is  the  i-th  element  of  the  process 
node  vector  for  T.  Thus,  S  -*->  T*  where  Pi  is  not 
blocked  in  T*,  and  the  execution  by  Pi  of  the  instruction 
for  node  Qi *  changes  state  T*  to  state  T.  Let  Vj  be  the 
vector  corresponding  to  node  Qi'.  Since  Pi  is  not  blocked 
in  T',  then  Pj  is  not  blocked  in  VASS(T'),  and  hence  Pj  is 
not  deadlocked  in  VASS  (S)  .  Since  Qi'  was  an  arbitrary 
node  in  an  arbitrary  process  graph,  then  for  any  process 
Pj  in  VAS(SS),  Pj  is  not  deadlocked  in  S.  We  have  now 
shown  that  if  S  is  safe  then  VASS  (S)  is  not  a  deadlock 
state.  From  Lemma  6.2(4),  for  all  X  such  that 
VASS  (S)  -*->  X,  there  exists  S*  such  that  S  -*->  S'.  But 
if  S  -*->  S',  then  S'  is  safe  and  thus  X=VASS(S')  is  not  a 
deadlock  state.  Hence  for  all  X  such  that  VASS(S)  -*->  X, 

t 

X  is  not  a  deadlock  state,  i.e.,  VASS  (S)  is  a  safe  state. 
Therefore,  if  S  is  safe,  then  VASS(S)  is  also  safe. 

Finally,  we  prove  part  (2)  of  Lemma  6.3.  From  Lemma 
6.3(1)  S  is  safe  if  and  only  if  VASS(S)  is  safe,  so  (2) 
can  be  proved  by  showing  that  RS  (S)  finite  if  and  only  if 
RS ( VASS  (S) )  finite.  Let  us  assume  that  RS (S)  is  finite. 
RS ( V ASS  {S ) )  must  also  be  finite  because  (a)  if 
VASS(S)  -*->  X  then  S  -*->  S*  where  V ASS(S*)=X  and  (b)  the 
mapping  VASS  is  many  to  one.  Now  let  us  assume  RS (S)  is 

It  must  be  that  S  -*->  S'  where  some  semaphore 


infinite. 
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in  S*  exceeds  any  given  bound.  But  S  -*->  s*  implies 
VASS  (S)  -*->  VASS  (S’) *  and  hence  some  element  of  VASS  (S') 
will  exceed  any  given  bound.  Thus,  there  is  an  unbounded 
number  of  states  VASS(S*)  such  that  VASS  (S)  — *— >  VASS  (S')# 
and  thus,  RS(VA SS  (S) )  is  infinite.  Therefore,  R3  (S)  is 
finite  if  and  only  if  RS(VASS(S))  is  finite,  and  S  is  self 
regulating  if  and  only  if  VASS  (S)  is  self  regulating. 

It  fellows  from  Lemma  6.3  that  one  can  determine  if  a 
state  in  a  semaphore  system  is  safe  or  self  regulating  by 
transforming  the  system  into  a  vector  addition  system,  and 
determining  the  corresponding  property  of  the  transformed 
system. 

Theorem  6 6  In  a  semaphore  system, 

(1)  it  is  decidable  if  a  state  is  a  deadlock  state,  and 

(2)  it  is  decidable  if  a  state  is  self  regulating. 

Proof  Let  S=  (  (Q 1 ,.  .  .  ,  Qi ,.  .  .  ,Qn)  ,  r)  .  First  we  show  that 
it  is  decidable  if  process  Pi  is  deadlocked  in  S. 
Clearly,  Pi  can  be  deadlocked  only  if  the  only  son  of  node 
Qi  is  Qi*  where  the  instruction  for  Qi*  is  a  request.  Let 
the  instruction  for  Qi*  be  1=  (II ,12 ,.. . ,Im) .  Process  Pi 
is  not  deadlocked  if  and  only  if  S  -*->  (Q*,r*)  such  that 
l+r*>0.  It  is  easily  shown  that  S  -*->  (Q*,r*)  such  that 
l+r>0  if  and  only  if  VASS (S)  -*->  X  where 

X=  (X 1  ,X2, . . . , Xm, - )  and  (X1,X2,< - ,Xra)+I>0.  Let  us 

define  Y=  (Y  1 , Y2, .. . ,Ym , . .. )  such  that  for  1<k<m, 
Yk  =  max  (-lk,0)  and  for  m+1<k<ro+c,  Yk  =  0.  Clearly, 
(XI ,X2,.. . ,Xm) +i>0  if  and  only  if  X>Y. 


By  Corollary 
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6.1(1)  it  is  decidable  if  VASS(S)  -*->  X  such  that  X  >  Y, 
and  thus,  it  is  also  decidable  if  Pi  is  deadlocked  in  S. 
Since  it  is  decidable  if  an  arbitrary  process  in  S  is 
deadlocked,  it  is  decidable  if  s  is  a  deadlock  state. 

Part  (2)  of  the  theorem  follows  immediately  from 
Lemma  6.3(2)  and  Theorem  6.5(2). 

Unfortunately,  there  is  no  known  algorithm  to  determine 
if  a  state  in  a  semaphore  system  is  safe,  and  we  are  left  with 
the  following  “corollary "  of  Conjecture  6.2. 

22Hi^cture  6^.3  In  a  semaphore  system  it  is  not  decidable 
if  a  state  is  safe. 

In  this  chapter  we  defined  a  model  of  interacting 
processes,  called  semaphore  systems,  which  includes  the 
process  flow  charts.  By  translating  semaphore  systems  into 
claim  limited  consumable  resource  systems,  simple  conditions 
were  developed  which  are  sufficient  for  deadlock  or  safeness. 
By  translating  semaphore  systems  into  vector  addition  systems, 
it  was  shown ‘that  it  is  decidable  if  a  state  is  deadlocked  or 
self  regulating.  The  guestion  of  whether  it  is  decidable  if  a 
state  in  a  semaphore  system  is  safe  remains  open. 
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Figu  re  6.11  Dijkstra's  example  (from  Figure  6*2)  as  a  10  by  12 
vector  addition  system.  The  vector  addition  system  is 
represented  by  its  graph  model. 
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CHAPTER  7.  CONCLUSION 
7.1  Summary  of  Thesis 

In  this  thesis  we  have  presented  an  extensive,  unified 
investigation  of  the  deadlock  problem  in  computer  systems. 
The  investigation  has  been  extensive  in  that  it  has  covered  a 
wide  range  of  topics  within  the  deadlock  problem,  including 
deadlock  prevention,  detection,  and  recovery,  and  it  has 
developed  several  models  of  process  interactions,  including 
reusable  resource  systems,  consumable  resource  systems,  and 
semaphore  systems.  The  investigation  has  been  unified  in  that 
throughout  the  thesis,  a  common  set  of  basic  definitions  has 
been  used;  these  definitions  include  the  specification  of  what 
it  means  for  a  process  to  be  ’’blocked”  or  ’’deadlocked”  and  for 
a  system  to  be  ’’safe”  from  deadlock. 

We  will  briefly  summarize  the  thesis  by  discussing:  (1) 
the  basic  definitions  used  throughout  the  thesis,  (2)  the 
models  of  systems  of  interacting  processes,  and  (3)  the 
theoretic  and  practical  results  developed  for  each  model. 

(1)  Basic  Definitions 

The  terms  ’’blocked”,  ''deadlocked”,  and  ’’safe”  were 
defined  without  specifying  the  exact  nature  of  either 
’’processes”  or  "systems”.  Essentially,  all  that  was  assumed 
about  systems  was  that  (a)  there  is  some  number  of  processes 
in  a  system,  and  (b)  a  process  is  a  set  of  rules  for  changing 
the  "environment”  (system  state).  A  process  was  defined  to  be 
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"blocked"  when  it  was  (perhaps  temporarily)  not  able  to  change 
the  environment,  A  process  was  defined  to  be  ’'deadlocked” 
when  it  would  never  be  able  to  change  the  environment,  A 
system  was  defined  to  be  ’’safe”  if  no  process  could  become 
deadlocked . 

In  all  models  given  in  the  thesis,  the  processes 
interacted  via  a  number  of  "resources”.  Each  resource 
consisted  of  a  number  of  identical  units,  and  the  processes 
changed  the  environment  by  increasing  and  decreasing  the 
numbers  of  units  of  the  resources.  In  each  model  a  process 
became  blocked  when  its  rules  for  changing  the  environment 
required  decreasing  the  number  of  available  units  of  a 
resource  to  less  than  zero, 

A  system  was  defined  to  be  "self  regulating"  when  no 
process  could  become  deadlocked  and  the  numbers  of  units  of 
all  resources  in  the  system  were  bounded, 

(2)  Systems  of  Interacting  Processes 

Several  models  of  interacting  processes  were  developed, 
and  the  basic  definitions  were  applied  to  each  of  these 
models.  Intuitive  graphical  interpretations  were  given  for 
each  of  these  models. 

The  first  two  models,  reusable  resource  systems  and 
consumable  resource  systems,  were  characterized  by  the 
properties  of  their  resources.  In  a  reusable  resource  system, 
a  unit  of  a  resouce  was  "borrowed"  from  the  environment  by  a 
process;  the  borrowed  unit  could  then  be  returned  to  the 


SECTION  7.1  234 


environment  by  the  borrowing  process.  Thus,  the  total  number 
of  units  in  a  reusable  resource  system  never  changed. 
Reusable  resource  systems  are  intended  to  model  computer 
systems  in  which  the  processes  share  physical  devices  (or 
objects  which  behave  like  physical  devices) . 

In  a  consumable  resource  system,  new  units  of  a  resource 
can  be  ’'produced”  by  processes;  existing  units  of  resources 
can  be  "consumed"  by  processes.  Thus,  the  number  of  units  in 
a  consumable  resource  system  is  not  fixed.  Consumable 
resource  systems  are  intended  to  model  computer  systems  in 
which  processes  communicate  with  each  other  by  passing 
"messages"  —  each  message  is  a  unit  of  a  consumable  resource. 

In  Chapter  5,  reusable  and  consumable  resource  systems 
were  combined  into  general  resource  systems.  In  a  general 
resource  system  the  processes  can  both  share  physical  devices 
and  pass  messages. 

In  Chapter  6  semaphore  systems  were  developed.  In  a 

i 

semaphore  system,  each  process  is  specified  by  a  flow  chart, 
which  determines  the  process’s  requests  and  releases  of 
resources.  A  semaphore  system  describes  processes  in 
considerably  more  detail  than  do  reusable  resource  systems  and 
consumable  resource  systems.  Consequently,  the  methods  of 
detecting  and  preventing  deadlock  in  semaphore  systems  are 
considerably  more  difficult  than  in  the  other  models. 

(3)  Results  for  the  Models 


We  will  give  a  brief  overview  of  the  results  obtained  for 
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the  various  models.  (See  Section  1.4  for  a  chapter  by  chapter 
listing  of  the  new  material  presented  in  this  thesis.) 

For  all  models,  necessary  and  sufficient  conditions  for  a 
process  to  be  deadlocked  were  developed.  For  most  models 
necessary  and  sufficient  conditions  for  a  system  to  be  safe 
from  deadlock  were  developed. 

Relationships  between  the  models  were  investigated.  In 
Chapter  5  it  was  shown  that  reusable  and  consumable  resource 
systems  could  be  combined  (into  general  resource  systems) ,  and 
that  many  results  and  algorithms  could  be  carried  over  to  the 
combined  system.  It  was  shown  that  consumable  resource 
systems  can  ’’mimic”  semaphore  systems,  and  that  deadlock  or 
safeness  in  the  mimicking  system  implies  deadlock  or  safeness 
in  the  mimicked  system. 

A  number  of  fast  algorithms  were  presented  for  detecting 
and  preventing  deadlock  in  reusable  resource  systems, 
consumable  resource  systems,  and  general  resource  systems. 
Most  of  these  algorithms  are  linear  (their  maximum  execution 
time  increases  linearly  with  the  number  of  processes),  while 
the  only  previously  known  algorithms  are  quadratic.  These 
algorithms  should  be  useful  in  practical  computing  systems, 
and  suggestions  for  their  use  were  given  in  the  form  of 
implementations  of  "request”  and  '’release"  operations  in 
Chapter  5. 

It  was  shown  that  it  is  decidable  if  a  state  in  a 
semaphore  system  is  deadlocked  or  self  regulating.  For 
semaphore  systems  of  modest  size,  it  may  be  practical  to 
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perform  an  analysis  {execute  an  algorithm)  to  determine  if  the 
system  state  is  self  regulating.  However,  there  are  no  known 
fast  algorithms  for  detecting  and  preventing  deadlock  in 
semaphore  systems.  The  author  expects  that  the  understanding 
gained  about  the  deadlock  problem,  rather  than  the  development 
of  practical  algorithms,  will  be  the  main  benefit  from  the 
study  of  semaphore  systems. 
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7.2  Suggest  ions  for  Future  Work 

The  author  feels  that  the  models  given  in  this  thesis  are 
good  models  of  computer  systems,  but  they  are  certainly  not 
the  only  good  models.  The  division  of  resources  into  reusable 
and  consumable  resources  seems  quite  reasonable,  but  it  is  not 
the  only  possible  characterization  of  resources.  Another 
researcher  might  develop  other  methods  of  characterizing 
resources  and  other  models  of  computing  systems.  Such  a 
researcher  would  probably  benefit  from  the  basic  definitions 
presented  in  Chapter  2  and  from  the  methods  of  proof  used  in 
Chapters  3  through  6. 

In  the  models  developed  in  this  thesis,  it  was  assumed 
that  the  numbers  of  processes  and  the  number  of  resources  in  a 
system  were  fixed.  This  assumption  is  not  essential  in  that 
most  of  the  results  obtained  will  still  be  true  when  new 
operations  are  added  which  allow  the  introduction  or  deletion 
of  processes  and  resources.  Other  operations  can  easily  be 
introduced  which  allow  the  simultaneous  allocation  of  reusable 
resources  to  more  than  one  process.  Such  operations  actually 
exist  in  many  computer  systems,  and  it  may  be  worthwhile  to 
formalize  these  additional  operations  and  to  show  what  effect 
they  have  upon  the  deadlock  properties  of  the  models. 

There  was  a  strong  suggestion  in  Section  3. 1  that  the 
only  interactions  among  processes  in  an  operating  system 
should  be  via  reusable  or  consumable  resources.  The  only  way 
to  show  that  this  suggestion  is  workable  is  to  implement  an 
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operating  system;  in  this  operating  system  there  would  be  no 
"events”,  "messages",  "signals",  or  "interrupts".  Instead, 
there  would  only  be  "resources".  Weiderman  [1971]  is 
presently  investigating  such  operating  systems.  Hopefully, 
his  research  will  demonstrate  that  "resources"  are,  indeed,  a 
convenient  and  sufficient  vehicle  for  all  process  interactions 
in  an  operating  system. 

Two  enticing  guestions  were  left  open  about  semaphore 
systems  (and  vector  addition  systems) ;  the  guestions  were: 

(1)  Is  it  decidable  if  one  state  can  be  reached  from 
another  state? 

(2)  Is  it  decidable  if  a  state  is  safe? 

The  investigations  in  this  thesis  benefit  in  nc  way  from 
probability  theory.  The  system  models  presented  could  easily 
be  transformed  into  Markov  chains  by  attaching  a  probability 
to  each  state  change.  Once  these  probabilities  have  been 
introduced,  a  number  of  interesting  questions  appear: 

i 

(1)  What  is  the  mean  time  to  deadlock? 

(2)  With  reusable  resources,  when  is  it  cheaper  to  prevent 
deadlock  and  when  is  it  cheaper  to  detect  deadlock? 

(3)  What  is  a  "reasonable"  utilization  of  reusable 
resources  if  deadlock  is  to  be  rare  (or  nonexistent) ? 


■ 
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APPENDIX  1 

IMPLEMENTATION  OF  BLOCK,  WAKEUP, 
MUTEXBEGIN,  AND  MUTEXEND  IN  PL/I 


BLOCK:  PROCEDURE  (P)  RECURSIVE; 
DECLARE  P  BINARY  FIXED  (15); 

WAIT (PRI VE V ENT  (P)  )  ; 

COMPLETION  (PRIVEVENT  (P) )  =  *0*B; 
END  BLOCK; 


WAKEUP:  PROCEDURE  (P)  RECURSIVE; 
DECLARE  P  BINARY  FIXED  (15); 
COMPLETION  (PRIVEVENT  (P)  )  =  M'B; 

END  WAKEUP; 


MUTEXBEGIN:  PROCEDURE (P)  RECURSIVE; 

DECLARE  P  BINARY  FIXED (15); 

REQMUTEX (P)  =  1 1  *  E ; 

CALL  WAKEUP  (CTLMUTEX)  ; 

CALL  BLOCK  (P)  ;  /*WAKEUP  IS  BY  CONTROL MUTEX-*/ 
END  MUTEXBEGIN; 


MUTEXEND:  PROCEDURE  (P)  RECURSIVE; 
DECLARE  P  BINARY  FIXED(15) ; 
MUTEX  =  1 1 »  B; 

CALL  WAKEUP  (CTLMUTEX)  ; 

END  MUTEXEND; 


CONTROLMUTEX:  PROCEDURE; 

/*THIS  IS  A  SPECIAL  CYCLIC  PROCESS.*/ 

DECLARE  (P,I)  BINARY  FIXED  <15); 

MUTEX  =  * 1*E;  /*NC  PROCESS  HAS  MUTUAL  EXCLUSION.*/ 

p  =  i; 

DO  WHILE  {*  1  »B)  ; 

/*BLOCK  UNTIL  WAKED  UP  BY  MUTEXBEGIN  OR  MUTEXEND.*/ 
CALL  BLOCK (CTLMUTEX) ; 

DO  I  =  1  TO  N  WHILE  (MUTEX)  ; 

IF  REQMUTEX  (P)  THEN 
DO; 

MUTEX  =  *  0  *B ; 

REQMUTEX (P)  -  »0«B; 

CALL  WAKEUP  (P)  ; 

END; 

P  =  MOD  (P,  N)  +  1; 

END; 

END  ; 

END  CONTROLMUTEX; 
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